Visit our newest sister site!
Hundreds of free aircraft flight manuals
Civilian • Historical • Military • Declassified • FREE!


TUCoPS :: Linux :: General :: netapp1.htm

NetApp Filer software versions 5.x firmware problems



Vulnerability

    NetApp Filer

Affected

    NetApp Filer software versions 5.x

Description

    Jason  Downs   found  following.    He  was   going  through   the
    documentation  for  version  5.2.1  (the  latest)  of  the Network
    Appliance Filer operating system when he stumbled upon this little
    gem:

        "Use the disk_fw_update command to update out-of-date firmware
        on all disks  or a specified  disk on a  filer. Each filer  is
        shipped with a /etc/disk_fw directory that contains the latest
        firmware revisions."

        [...]

        "In the /etc/disk_fw directory,  the firmware file name  is in
        the  form  of  product_ID.revision.LOD.  For  example,  if the
        firmware file is for  Seagate disks with product  ID ST19171FC
        and  the  firmware  revision  is   FB37,  the  file  name   is
        ST19171FC.FB37.LOD.   The  revision  in  the  file name is the
        number against which the  filer compares each disk's  existing
        firmware revision."

        [...]

        "Before  Data  ONTAP  5.2,  the  disk_fw_update command copied
        firmware files from the /etc directory. In the /etc directory,
        the  name  for   the  firmware  file   was  in  the   form  of
        product_ID.LOD. The  revision number  was not  included in the
        file name.  Data ONTAP 5.2 continues to support firmware files
        in the /etc directory for backward compatibility.  That is, if
        you  obtain  a  disk  firmware  file  and store it in the /etc
        directory, you can use the disk_fw_update command to copy that
        firmware file to disks, unless  there is also a firmware  file
        for the same  product ID in  the /etc/disk_fw directory.   The
        files in the /etc/disk_fw  directory take precedence over  the
        files in the /etc directory."

        [...]

    Filer's  typically  have  an  "admin  host"  which  can  mount and
    read/write  to  the  filer  root  directory.   Without  it,   it's
    impossible to do any sort of system maintenance on the filer.   If
    this host is  compromised it's obviously  bad news for  the filer.
    But  now,  apparently  new  with  the  5.x  revisions of the filer
    operating system,  a malicious  individual can  likely destroy the
    disk drive hardware itself.  It is not known if any sort of sanity
    check is done on the  contents of the firmware files;  it's likely
    there is  none, considering  the type  of code  they contain.   Of
    course, it is trivial to gain command line access to a filer  once
    the  admin  host  is  compromised.   They  use  what  amounts   to
    /etc/hosts.equiv for rsh access.  It has always been important  to
    make sure the  "admin host" of  a filer is  secure.  Now  it seems
    Network Appliance  has just  raised the  stakes; not  only can you
    lose your  data, but  you can  also potentially  lose hundreds  of
    thousands of dollars worth of hardware.

    Kragen  Sitaker  added  following.    His  biggest  concern   with
    upgradable firmware  is much  more severe.   If you  can "upgrade"
    the firmware on  the disk somebody  boots their machine  from, you
    can theoretically do unbelievably devilish things.  You can insert
    arbitrary code into the OS kernel, for example, but only when  you
    boot off that  disk; if you  boot off a  floppy to check  the disk
    with Tripwire  or L5,  you can  give the  unmodified kernel.  Most
    disks  have  plenty  of  spare  space  on  them  --  reserved  for
    remapping bad  blocks --  and you  would have  plenty of  space to
    store  whatever  malicious  code  you  wanted.   You  could,   for
    instance, insert nonstandard options into IP headers and use  them
    as  a  covert   channel  to  alert   you  of  the   existence  and
    configuration of infected machines.  You could send extra  packets
    during times  of heavy  traffic.   You could  insert extra queries
    into DNS packets -- queries that would ultimately be forwarded  to
    malicious DNS servers.   Once you'd found  infected machines,  you
    could exert complete control over them.  A particularly  obnoxious
    possibility: you could insert "logic bombs" into the disk firmware
    that would activate only when certain (long and rather improbable,
    perhaps a few hundred bytes) were  read from the disk.  Then  spam
    people  with  a   .gif  containing  that   sequence,  along   with
    steganographically-encoded machine  code.   They extract  the .gif
    onto their disk,  nicely aligned with  the beginning of  a sector,
    and load it  up with Netscape.   And if your  breakin was  spotted
    and the machine reinstalled from scratch, it wouldn't matter.  The
    machine would still be compromised,  and there would be no  way to
    tell that it was compromised,  since you can't check the  firmware
    with L5.

Solution

    Nothing  yet.   These  feats  would  be  technically difficult and
    narrowly applicable,  requiring detailed  knowledge of  particular
    disk designs and operating systems.   But the threat is much  more
    severe than the mere threat of someone breaking into your  machine
    and stealing or  deleting your data.   Firmware that is  flashable
    without requiring inconvenient physical access are bad.


TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2014 AOH