Intel Chips, Code for ultimate rootkit to be released on 19 March 2009

Discussion in 'Computer Support' started by Pennywise@DerryMaine.Gov, Mar 19, 2009.

  1. Guest

    "This is the scariest, stealthiest, and most dangerous exploit I've
    seen come around since the legendary Blue Pill! No, I'm not just
    trying to sensationalize this or spread fear, uncertainty and doubt.
    This is serious and represents a massive new security threat for us
    all."

    Kind of a panic post huh?

    Just my luck I have an Intel Chip.

    The exploit
    http://www.networkworld.com/community/node/39825
    How it works
    http://blogs.techrepublic.com.com/security/?p=1130
    Slashdot article
    http://it.slashdot.org/article.pl?sid=09/03/19/179228


    --

    NYC Sitcom Map
    http://23.media.tumblr.com/IwM8PIQ02kudgmreiD4AhpNyo1_r1_500.png
     
    , Mar 19, 2009
    #1
    1. Advertising

  2. chuckcar Guest

    wrote in
    news::

    >
    > "This is the scariest, stealthiest, and most dangerous exploit I've
    > seen come around since the legendary Blue Pill! No, I'm not just
    > trying to sensationalize this or spread fear, uncertainty and doubt.
    > This is serious and represents a massive new security threat for us
    > all."
    >
    > Kind of a panic post huh?
    >
    > Just my luck I have an Intel Chip.
    >
    > The exploit
    > http://www.networkworld.com/community/node/39825
    > How it works
    > http://blogs.techrepublic.com.com/security/?p=1130
    > Slashdot article
    > http://it.slashdot.org/article.pl?sid=09/03/19/179228
    >

    For article #1:

    Big deal. It's called a hardware interrupt. *If* as he claims it happened in
    386's, that's the *only* possibility. Of course the possibility that he's
    commenting on something he neither understands nor knows *anything* about
    - pointed to by his complete lack of details - is a strong possibility.


    Apparently he *doesn't* know shit:

    http://www.rcollins.org/ddj/Jan97/Jan97.html

    For Article #2:

    SMM exists in processors from the 386 onward. It's a physical *pin* on the chip
    itself which is not unlike a hardware interrupt pin on earlier processors. That is
    hardware *physically* on the motherboard sends a pulse to this pin telling the
    computer it needs something done.


    Finally in article #3 they actually *mention* and give a bloodly link to the article.

    http://invisiblethingslab.com/itl/Resources.html


    All the above of course would require a computer to be at *least* already infected
    with malware to do *anything*.

    --
    (setq (chuck nil) car(chuck) )
     
    chuckcar, Mar 19, 2009
    #2
    1. Advertising

  3. Guest

    , Mar 19, 2009
    #3
  4. Re: Intel Chips, Code for ultimate rootkit to be released on 19 March2009

    wrote:
    > "This is the scariest, stealthiest, and most dangerous exploit I've
    > seen come around since the legendary Blue Pill! No, I'm not just
    > trying to sensationalize this or spread fear, uncertainty and doubt.
    > This is serious and represents a massive new security threat for us
    > all."
    >
    > Kind of a panic post huh?
    >
    > Just my luck I have an Intel Chip.
    >
    > The exploit
    > http://www.networkworld.com/community/node/39825
    > How it works
    > http://blogs.techrepublic.com.com/security/?p=1130
    > Slashdot article
    > http://it.slashdot.org/article.pl?sid=09/03/19/179228
    >
    >

    YEh...saw it on slashdot...too bad you have new kit...it wont touch my
    old crap I get for free :)



    --
    http://www.palindeception.com/
    http://palinpics4truth.blogspot.com
     
    §ñühw¤£f, Mar 19, 2009
    #4
  5. Guest

    , Mar 19, 2009
    #5
  6. chuckcar Guest

    wrote in
    news::

    > chuckcar <> wrote:
    >
    >>> Slashdot article
    >>> http://it.slashdot.org/article.pl?sid=09/03/19/179228
    >>>

    >>For article #1:

    >
    >>Big deal. It's called a hardware interrupt. *If* as he claims it
    >>happened in 386's, that's the *only* possibility.

    >
    > Read the slashdot replies, one observes it will set in the BIOS and
    > there is a question of space for it.
    >

    Well, no matter what it *can't* do more than a virus does already: infect
    the OS, put a hook on the MBR and possibly the BIOS nvram, delete files,
    send mail. The limits of what can possibily be done by a trojan/virus are
    reached by BIOS calls. If you go any lower, you loose capabilities *big*
    time and have to *really* know machine language, which put it into the
    camp of the hackers (original meaning here). This would mean that they're
    far they're more likely to get caught quickly because the number of malware
    pieces goes down severely along with the number of people actually doing
    such code. Along with increased effort/desire to catch them.


    --
    (setq (chuck nil) car(chuck) )
     
    chuckcar, Mar 20, 2009
    #6
  7. Evan Platt Guest

    On Fri, 20 Mar 2009 21:48:38 +0000 (UTC), chuckcar <>
    wrote:

    >Well, no matter what it *can't* do more than a virus does already:


    Your advice is much worse than any virus could ever hope to be.
    --
    To reply via e-mail, remove The Obvious from my e-mail address.
     
    Evan Platt, Mar 20, 2009
    #7
  8. Guest

    chuckcar <> wrote:

    > wrote in
    >news::
    >
    >> chuckcar <> wrote:
    >>
    >>>> Slashdot article
    >>>> http://it.slashdot.org/article.pl?sid=09/03/19/179228
    >>>>
    >>>For article #1:

    >>
    >>>Big deal. It's called a hardware interrupt. *If* as he claims it
    >>>happened in 386's, that's the *only* possibility.

    >>
    >> Read the slashdot replies, one observes it will set in the BIOS and
    >> there is a question of space for it.


    >Well, no matter what it *can't* do more than a virus does already:


    You missed the point as usual, this makes in undetectable.
    --

    pics of the undersea volcanic eruptions near Tonga
    www.boston.com/bigpicture/2009/03/undersea_eruptions_near_tonga.html
     
    , Mar 20, 2009
    #8
  9. chuckcar Guest

    wrote in
    news::

    > chuckcar <> wrote:
    >
    >>Finally in article #3 they actually *mention* and give a bloodly link to
    >>the article.
    >>
    >>http://invisiblethingslab.com/itl/Resources.html

    >
    > This is the release of the exploit, as posted by Rafal Wojtczuk and
    > Joanna Rutkowska as mentioned in the slashdot.org article.
    >
    > Read the code and see for yourself what it does
    > http://invisiblethingslab.com/resources/misc09/o68-2.tgz


    I saw the link by way of the slashdot article, I have no interest in
    spending an hour to half a day decoding ML to no real point thankyou.

    --
    (setq (chuck nil) car(chuck) )
     
    chuckcar, Mar 20, 2009
    #9
  10. chuckcar Guest

    wrote in
    news::

    > chuckcar <> wrote:
    >
    >> wrote in
    >>news::
    >>
    >>> chuckcar <> wrote:
    >>>
    >>>>> Slashdot article
    >>>>> http://it.slashdot.org/article.pl?sid=09/03/19/179228
    >>>>>
    >>>>For article #1:
    >>>
    >>>>Big deal. It's called a hardware interrupt. *If* as he claims it
    >>>>happened in 386's, that's the *only* possibility.
    >>>
    >>> Read the slashdot replies, one observes it will set in the BIOS and
    >>> there is a question of space for it.

    >
    >>Well, no matter what it *can't* do more than a virus does already:

    >
    > You missed the point as usual, this makes in undetectable.


    No, you're *not* rewriting the microcode. The x86/Px chip is *not* a
    microcode reprogramable CPU. At worst you do as above. Somewhere there
    will be a file storing the code and that file will show the malware is
    present. That cannot be avoided. And since at least *one* of these files
    is *always* the same (at least a part of it) it *is* detectable.

    --
    (setq (chuck nil) car(chuck) )
     
    chuckcar, Mar 21, 2009
    #10
  11. G. Morgan Guest

    chuckcar wrote:

    >Somewhere there
    >will be a file storing the code and that file will show the malware is
    >present.



    If you read the articles, which I doubt, you would have read about the rogue
    code being stored on unused portions of the CMOS.
     
    G. Morgan, Mar 21, 2009
    #11
  12. chuckcar Guest

    G. Morgan <> wrote in
    news::

    > chuckcar wrote:
    >
    >>Somewhere there
    >>will be a file storing the code and that file will show the malware is
    >>present.

    >
    >
    > If you read the articles, which I doubt, you would have read about the
    > rogue code being stored on unused portions of the CMOS.
    >

    What the hell, I'll play with the idiot. You can't store *anything* in
    CMOS ram even *approaching* the code required for *any* virus, much less a
    trojan. Besides, *all* AV software scans this memory (and the main memory)
    and it can be cleared without opening the case very easily. The ROM memory
    of course *can't* be written to, leaving nothing.


    --
    (setq (chuck nil) car(chuck) )
     
    chuckcar, Mar 21, 2009
    #12
  13. Evan Platt Guest

    On Sat, 21 Mar 2009 13:30:53 +0000 (UTC), chuckcar <>
    wrote:

    >What the hell, I'll play with the idiot.


    Pot. Kettle.
    --
    To reply via e-mail, remove The Obvious from my e-mail address.
     
    Evan Platt, Mar 21, 2009
    #13
  14. G. Morgan Guest

    chuckcar wrote:

    >> If you read the articles, which I doubt, you would have read about the
    >> rogue code being stored on unused portions of the CMOS.
    >>

    >What the hell, I'll play with the idiot.


    Okay, tardo. Do so at your own peril.


    > You can't store *anything* in
    >CMOS ram even *approaching* the code required for *any* virus, much less a
    >trojan.


    Really?

    Look at the comment by "FrankSchwab", a firmware engineer:
    http://it.slashdot.org/article.pl?sid=09/03/19/179228

    "As a firmware engineer who patches ROM code in embedded systems daily, I'll
    give a bit of insight.

    The BIOS as a whole is specific to the board that it is running on. However,
    that doesn't mean that additions can't be made to the BIOS in a generic
    fashion. Imagine you searched the BIOS Flash for unused space (all of them
    will have it), and relocated code into that space (relocating a DOS .exe file
    is trivial). Writing a FLASH is not a difficult operation, though different
    motherboard manufacturers probably write protect it in different ways. Your
    code is now in the BIOS ROM.

    You then modify the code in the flash that handles e.g. INT 14 (Serial
    communications, pretty much a dead function on modern PCs). This is nothing
    more than overwriting the first couple of bytes of the address pointed to by
    the INT14 vector in the flash - you store them in your patch area, and JMP to
    your routine. Once again, it's a Flash write.

    Now, certainly, at some point in time (BIOS, probably) someone will attempt to
    enumerate/initialize the serial ports. Your code is now running - the world is
    your oyster. With this exploit, you can now probably hoist the BIOS code into
    a VM PRIOR to loading Windows. And you're still there.

    There are different families of BIOS that you would have to support - Phoenix,
    AMI (do they still exist?), HP, Intel, etc. There are different schemes for
    protecting Flash, etc. These differences are probably smaller than they
    sound."


    > Besides, *all* AV software scans this memory (and the main memory)
    >and it can be cleared without opening the case very easily.


    Again, in the article:
    http://www.networkworld.com/community/node/39825

    "The heart-stopping thing about this particular exploit is that it hides
    itself in the SMM space. To put that into perspective, SMM is more privileged
    than a hypervisor is and it's not controllable by any Operating System. By
    design, the operating system cannot override or disable System Management
    Interupt (SMI) calls. In practice, the only way for you to know what is
    running in SMM space is to physically disassemble the firmware of your
    computer."


    > The ROM memory
    >of course *can't* be written to, leaving nothing.


    That is exactly opposite of what the exploit can do, Tardo.
     
    G. Morgan, Mar 21, 2009
    #14
  15. chuckcar Guest

    G. Morgan <> wrote in
    news::

    > chuckcar wrote:
    >
    >>> If you read the articles, which I doubt, you would have read about the
    >>> rogue code being stored on unused portions of the CMOS.
    >>>

    >>What the hell, I'll play with the idiot.

    >
    > Okay, tardo. Do so at your own peril.
    >
    >
    >> You can't store *anything* in
    >>CMOS ram even *approaching* the code required for *any* virus, much less
    >>a trojan.

    >
    > Really?
    >
    > Look at the comment by "FrankSchwab", a firmware engineer:
    > http://it.slashdot.org/article.pl?sid=09/03/19/179228
    >
    > "As a firmware engineer who patches ROM code in embedded systems daily,
    > I'll give a bit of insight.
    >
    > The BIOS as a whole is specific to the board that it is running on.


    Meaning that it a) won't work on any machine where the write pin for the EPROM
    is disconnected. Not an unlikely possibility.

    > However, that doesn't mean that additions can't be made to the BIOS in a
    > generic fashion. Imagine you searched the BIOS Flash for unused space
    > (all of them will have it), and relocated code into that space
    > (relocating a DOS .exe file is trivial). Writing a FLASH is not a
    > difficult operation, though different motherboard manufacturers probably
    > write protect it in different ways. Your code is now in the BIOS ROM.
    >
    > You then modify the code in the flash that handles e.g. INT 14 (Serial
    > communications, pretty much a dead function on modern PCs). This is
    > nothing more than overwriting the first couple of bytes of the address
    > pointed to by the INT14 vector in the flash - you store them in your
    > patch area, and JMP to your routine. Once again, it's a Flash write.
    >
    > Now, certainly, at some point in time (BIOS, probably) someone will
    > attempt to enumerate/initialize the serial ports. Your code is now
    > running - the world is your oyster. With this exploit, you can now
    > probably hoist the BIOS code into a VM PRIOR to loading Windows. And
    > you're still there.
    >
    > There are different families of BIOS that you would have to support -
    > Phoenix, AMI (do they still exist?), HP, Intel, etc. There are different
    > schemes for protecting Flash, etc. These differences are probably
    > smaller than they sound."
    >

    A wild guess.

    >
    >> Besides, *all* AV software scans this memory (and the main memory)
    >>and it can be cleared without opening the case very easily.

    >
    > Again, in the article:
    > http://www.networkworld.com/community/node/39825
    >
    > "The heart-stopping thing about this particular exploit is that it hides
    > itself in the SMM space. To put that into perspective, SMM is more
    > privileged than a hypervisor is and it's not controllable by any
    > Operating System. By design, the operating system cannot override or
    > disable System Management Interupt (SMI) calls. In practice, the only
    > way for you to know what is running in SMM space is to physically
    > disassemble the firmware of your computer."
    >
    >
    >> The ROM memory
    >>of course *can't* be written to, leaving nothing.

    >
    > That is exactly opposite of what the exploit can do, Tardo.
    >

    You'll have to better than that. For one you'll have to show how a ROM
    (alleged EEPROM - the only type this works for) can be a) rewritten and
    b) *has* the required 12v (or 16v sometimes - which *isn't* available on
    *any* computer) connection actually hooked up. If *any* of this was the
    case, it could have/would have been done *ages* ago without any hook into
    an interrupt which leaves a bare machine with *no* BIOS available in any case.
    The BIOS doesn't stop you from doing *anything* of this sort if it were
    possible. Ralf Browns interrupt list is easily found on the web and explains
    the BIOS *completely*.

    Along with all this you *would* need to be intimately aquainted with ML on
    Intel machines. VB and the like just couldn't do it.

    The hook could be disabled entirely by a BIOS ram wipe and reboot in any case
    as that's where the redirect is. This would leave a) a bit less free ROM space
    and b) the code with no pointer to it.

    --
    (setq (chuck nil) car(chuck) )
     
    chuckcar, Mar 21, 2009
    #15
  16. G. Morgan Guest

    chuckcar wrote:

    >You'll have to better than that. For one you'll have to show how a ROM
    >(alleged EEPROM - the only type this works for) can be a) rewritten and
    >b) *has* the required 12v (or 16v sometimes - which *isn't* available on
    >*any* computer) connection actually hooked up.


    You don't need to move a jumper to access BIOS. All you need is a program to
    access it. When you update a BIOS, you are accessing the EEPROM. Generally
    this is easily done by booting to DOS and running a small executable.


    > If *any* of this was the
    >case, it could have/would have been done *ages* ago without any hook into
    >an interrupt which leaves a bare machine with *no* BIOS available in any case.
    >The BIOS doesn't stop you from doing *anything* of this sort if it were
    >possible. Ralf Browns interrupt list is easily found on the web and explains
    >the BIOS *completely*.


    The reason I specifically said "CMOS" and not "BIOS" in my reply was an
    attempt to reduce your confusion (I didn't think it would work).

    The CMOS/EEPROM chip, where the BIOS is stored also serves as potential
    storage for small clips of rogue code.

    >Along with all this you *would* need to be intimately aquainted with ML on
    >Intel machines. VB and the like just couldn't do it.


    Read about the exploit again. Then read about SMM:
    http://en.wikipedia.org/wiki/System_Management_Mode


    >The hook could be disabled entirely by a BIOS ram wipe and reboot in any case
    >as that's where the redirect is. This would leave a) a bit less free ROM space
    >and b) the code with no pointer to it.


    And just how is this "BIOS ram wipe" performed?
     
    G. Morgan, Mar 21, 2009
    #16
  17. chuckcar Guest

    G. Morgan <> wrote in
    news::

    > chuckcar wrote:
    >
    >>You'll have to better than that. For one you'll have to show how a ROM
    >>(alleged EEPROM - the only type this works for) can be a) rewritten and
    >>b) *has* the required 12v (or 16v sometimes - which *isn't* available on
    >>*any* computer) connection actually hooked up.

    >
    > You don't need to move a jumper to access BIOS. All you need is a
    > program to access it.


    What jumper? This is a pin on the ROM chip.

    > When you update a BIOS, you are accessing the
    > EEPROM. Generally this is easily done by booting to DOS and running a
    > small executable.
    >

    That's to *completely* wipe it and re-write it. Hardly the same thing.

    >
    >> If *any* of this was the
    >>case, it could have/would have been done *ages* ago without any hook
    >>into an interrupt which leaves a bare machine with *no* BIOS available
    >>in any case. The BIOS doesn't stop you from doing *anything* of this
    >>sort if it were possible. Ralf Browns interrupt list is easily found on
    >>the web and explains the BIOS *completely*.

    >
    > The reason I specifically said "CMOS" and not "BIOS" in my reply was an
    > attempt to reduce your confusion (I didn't think it would work).
    >

    The BIOS routines *are* in the PROM. CMOS is a type of integrated circuit
    period. Operational amplifiers and a *lot* of analog hardware use CMOS
    type chips.

    > The CMOS/EEPROM chip, where the BIOS is stored also serves as potential
    > storage for small clips of rogue code.
    >

    ROMS are *not* CMOS period. A *lot* of RAM is CMOS due to the ability
    to get a higher density of bits on a chip. Virtually *all* CMOS chips
    are *extremely* shock sensitive, If you even touch one of the pins on one
    without wearing a ground strap, the chip *is* toast from the static discharge.
    That's *why* people wear a strap when they're working on computers.

    >>Along with all this you *would* need to be intimately aquainted with ML
    >>on Intel machines. VB and the like just couldn't do it.

    >
    > Read about the exploit again. Then read about SMM:
    > http://en.wikipedia.org/wiki/System_Management_Mode
    >

    I have. This is another point you don't have an answer for or understand.

    >
    >>The hook could be disabled entirely by a BIOS ram wipe and reboot in any
    >>case as that's where the redirect is. This would leave a) a bit less
    >>free ROM space and b) the code with no pointer to it.

    >
    > And just how is this "BIOS ram wipe" performed?
    >

    By using debug for one or a simple ML routine will do it. It's mapped to
    main memory so doing it is trivial.


    --
    (setq (chuck nil) car(chuck) )
     
    chuckcar, Mar 22, 2009
    #17
  18. Evan Platt Guest

    On Sun, 22 Mar 2009 18:57:50 +0000 (UTC), chuckcar <>
    wrote:

    <SNIP>

    How come I don't even need to read any of what you said to know it's
    100% wrong?
    --
    To reply via e-mail, remove The Obvious from my e-mail address.
     
    Evan Platt, Mar 22, 2009
    #18
  19. G. Morgan Guest

    Evan Platt wrote:

    >On Sun, 22 Mar 2009 18:57:50 +0000 (UTC), chuckcar <>
    >wrote:
    >
    ><SNIP>
    >
    >How come I don't even need to read any of what you said to know it's
    >100% wrong?


    I can't continue to argue with him because he won't get the vernacular right.
     
    G. Morgan, Mar 22, 2009
    #19
  20. chuckcar Guest

    G. Morgan <> wrote in
    news::

    > Evan Platt wrote:
    >
    >>On Sun, 22 Mar 2009 18:57:50 +0000 (UTC), chuckcar <>
    >>wrote:
    >>
    >><SNIP>
    >>
    >>How come I don't even need to read any of what you said to know it's
    >>100% wrong?

    >
    > I can't continue to argue with him because he won't get the vernacular
    > right.
    >

    Coming from someone who continues to *use* the vernacular and doesn't know
    what the terms mean, I see that as a compeltment.

    CMOS: an acronym for Complementary Metal Oxide Semiconductor. Prevalent in
    such common chips as ram, the 741 Operational amplifier and audio
    compnents.

    BIOS: The rom in a PC clone that a) allows the CPU to communicate with
    periferals with pre-written code and eliminates the need for b) a
    bootstrap loader.

    BIOS is ROM only. There *is* a section of NV (short for non-volatile - not
    needing refresh, but needing power from the battery) RAM *used* by this,
    but only for the aforementioned pointers and to store some machine
    hardware information and the time. This RAM - unlike the bulk of RAM in a
    PC clone is static RAM. The remainder is Dynamic ram which *does* require
    refreshes.

    --
    (setq (chuck nil) car(chuck) )
     
    chuckcar, Mar 22, 2009
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    0
    Views:
    401
  2. Giuen
    Replies:
    0
    Views:
    1,258
    Giuen
    Sep 12, 2008
  3. Tom
    Replies:
    3
    Views:
    1,357
    coder
    Aug 4, 2008
  4. BoBi
    Replies:
    0
    Views:
    325
  5. H1B Stings
    Replies:
    0
    Views:
    1,486
    H1B Stings
    May 9, 2009
Loading...

Share This Page