Slashdot Mirror

← Back to Stories (view on slashdot.org)

LightEater Malware Attack Places Millions of Unpatched BIOSes At Risk

Posted by timothy on from the nothing's-perfect dept.

Mark Wilson writes Two minutes is all it takes to completely destroy a computer. In a presentation entitled 'How many million BIOSes would you like to infect?' at security conference CanSecWest, security researchers Corey Kallenberg and Xeno Kovah revealed that even an unskilled person could use an implant called LightEater to infect a vulnerable system in mere moments. The attack could be used to render a computer unusable, but it could also be used to steal passwords and intercept encrypted data. The problem affects motherboards from companies including Gigabyte, Acer, MSI, HP and Asus. It is exacerbated by manufactures reusing code across multiple UEFI BIOSes and places home users, businesses and governments at risk.

83 comments

  1. Hardware is trusted by Anonymous Coward · · Score: 3, Interesting

    This was expected. A PC has many devices ready to accept new firmware at any moment. All you need is administrator access and you can start uploading new code. BIOS, HDD, DVD, even CPU microcode updates. Previously not that many have bothered, as it has been far more simple to just use some low-hanging Windows exploit. Now that Windows security has improved, blackhats have to up their game.

    1. Re:Hardware is trusted by Anonymous Coward · · Score: 1

      To be fair, people have been exploiting hardware for decades - this isn't new, though I suppose it's new-ish (less then a decade?) for casual black hats.

      56k modem exploits back in the day were kind of useful.

    2. Re:Hardware is trusted by aaaaaaargh! · · Score: 4, Insightful

      It would be easy to prevent such attacks by requiring a physical switch to make any changes to the BIOS possible. But that would give power to the end users instead of big industry, and we cannot have that, can we.

    3. Re:Hardware is trusted by DarkOx · · Score: 4, Interesting

      It would be easy to prevent such attacks by KISS as well. Sticking with something a lot more like BIOS instead of a multi-Megabyte EFI mess.

      --
      Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
    4. Re:Hardware is trusted by Anonymous Coward · · Score: 0

      It would be easy to prevent such attacks by requiring a physical switch to make any changes to the BIOS possible. But that would give power to the end users instead of big industry, and we cannot have that, can we.

      I don't see the industry as something that wants only to constantly fuck us in the ass. We have a lot of power as customers. When any Taiwanese motherboard manufacturer realizes that there is customer demand for this kind of physical switch, in couple of months we would have boards with a little switch with the text "FW_PROTECT" silkscreened next to it. That feature would also go right into their web pages in the list of other special features like dual BIOS, surge protection, high-quality capacitors and dehumidifier.

    5. Re:Hardware is trusted by AmiMoJo · · Score: 0

      UEFI is much better than the old BIOS system. It runs ROM code from PCI/PCI-e devices in a VM, for example. While Secureboot worries a lot of people, as long as the option to load your own keys exists it's a nice security enhancement. It boots a lot faster too, due in part to ditching a lot of legacy crap that was probably full of security holes too.

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
    6. Re:Hardware is trusted by Anonymous Coward · · Score: 0

      Too late. UEFI is built around writable flash memory. Just booting a different OS means writing to the same flash memory which allows this attack.

    7. Re:Hardware is trusted by DarkOx · · Score: 3, Insightful

      Not sold. Sticking with something like BIOS does not mean sticking with BIOS. Its time to drop the legacy support, sure. Sticking with a small amount of boot code to fire up the storage controller and jump to boot loader, set some memory timings etc is going to more secure than a massive interactive application that UEFI is.

      Fewer inputs mean fewer inputs to sanitize and less opportunity to screw it up.

      --
      Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
    8. Re:Hardware is trusted by Anonymous Coward · · Score: 0

      Why is writing to the flash required when booting?

    9. Re:Hardware is trusted by Jesus_666 · · Score: 4, Insightful

      It'd be nice if the next iteration of EFI had a more robust upgrade security design.

      Something like this: Firmware upgrades are not possible from inside the OS. At all. Instead there's a switch on the mainboard that is only accessible when the computer has been physically opened. When that switch is on, EFI will refuse to boot any OS and all onboard SATA/SCSI controllers are physically disabled. EFI will scan every USB port* for a FAT32-formatted mass storage device containing a file with a certain filename, which is then displayed for your approval, checked and installed. While the switch is off, changing the firmware should be prevented in hardware, such as by detaching a certain line required to write to the flash chip. (Settings should be stored on an unprotected chip and can be changed while the computer is bootable.)

      You're in a corporate setting and need to update 16.000 identical desktop computers all at once? Make sure the computers have an enterprise-ready mainboard that can pull the update from the network (e.g. using something similar to BOOTP). You'll still have to toggle that switch and confirm the prompt. That's as convenient as it should get; after all, if there is any chance that the firmware is modified while an OS is loaded, any successful attack on the OS leaves your firmware in a potentially compromised state.


      * Yeah, I know, USB also has infectable firmware. Unfortunately, I don't know of a reasonable mass storage standard that doesn't. And making people physically swap PROM chips won't fly.

      --
      USE HOT GRITS WITH STATUE OF NATALIE PORTMAN (NAKED AND PETRIFIED)
    10. Re:Hardware is trusted by Anonymous Coward · · Score: 0

      not previously exploited? There have been several out there that simply wrote FF,FF,FF to the first three bytes to the Bios to brick a machine on next boot.

      Also most decent motherboards have a Bios check and a secondary section of flash that will kick in if the bios does not pass checksum stored fro mthe last official load.

    11. Re:Hardware is trusted by Lumpy · · Score: 4, Informative

      Most older server motherboards had this. you had to install a jumper to enable write for Bios upgrades. Problem is the first thing you did as a sysadmin is install that jumper and leave it there.

      --
      Do not look at laser with remaining good eye.
    12. Re:Hardware is trusted by Anonymous Coward · · Score: 0

      It isn't technically required, as long as you stick to one configured OS or manually select the alternative OS every time, but since UEFI doesn't use an MBR, it uses flash memory for things that an MBR boot loader would store on the hard disk.

    13. Re:Hardware is trusted by gl4ss · · Score: 1

      just leave that portion writable and make everything else read only?

      besides, you would likely want to be notified if the boot disk was about to be changed anyways, wouldn't you?

      --
      world was created 5 seconds before this post as it is.
    14. Re: Hardware is trusted by Anonymous Coward · · Score: 0

      QEMU

    15. Re:Hardware is trusted by CrackerJackz · · Score: 2

      I would also settle for something that several of my (way old) Compaq servers had ... a second BIOS, SoftPAQ screw up your servers BIOS? Set a jump and boot from the factory fresh second BIOS (then re-flash the primary BIOS with a known good copy.) In modern systems just leave the default BIOS upgradeable (or a least require a PIN to update / trusted CA cert for enterprise deployments) and have a hardware button inside that can write the v1.0 BIOS code over the current chip. In this example the v1.0 BIOS can be hardware read-only (ROM-BIOS) as well.

    16. Re:Hardware is trusted by Anonymous Coward · · Score: 0

      To me that still seems that you only need to read flash memory while booting, and write it only when you update the boot loader OS configuration. Thus, a write protect jumper would still work just fine, and would actually offer the extra benefit of malware not tampering with the boot setup.

    17. Re:Hardware is trusted by Anonymous Coward · · Score: 0

      The problem isn't that it couldn't be done. Obviously the firmware can just be written to not require persistent writable memory. At the very least it could be made to exclusively use the UEFI partition on the hard disk for all configuration data. Technically you could put the firmware in ROM and have no flash memory at all, if that's what you wanted. The problem is that it's not designed to be implemented that way. IMHO that's exceptionally stupid design, but that's the way it is. There have already been cases of bricked* computers resulting from merely installing an operating system.

      *) bricked in the sense that special hardware was necessary for restoring functionality.

    18. Re:Hardware is trusted by IamTheRealMike · · Score: 2

      No, that would be useless. Just think it through a bit.

      OK, so you have a physical switch somewhere. Bear in mind the trend in laptop design is to try and eliminate ports and switches, so Jony Ive will throw a fit if you suggest such a thing and Apple won't do it. But let's pretend the PC makers all do.

      When does the user have to press this switch? When there's a BIOS update that needs to be applied.

      How do they know there's a BIOS update to be applied? Because a message pops up on their screen telling them there is one.

      How do they know the message comes from their PC manufacturer and not a virus? They don't.

      So will a virus just ask the user to press the button? Yes.

      And will the user comply? Yes.

      A physical switch will not stop BIOS malware.

    19. Re:Hardware is trusted by Anonymous Coward · · Score: 0

      It would be easy to prevent such attacks by requiring a physical switch to make any changes to the BIOS possible. But that would give power to the end users instead of big industry, and we cannot have that, can we.

      Sponsored by the NSA and every TLA out there, simply because they want to remotely install spyware into your BIOS. Be afraid, be very afraid.

    20. Re:Hardware is trusted by dog77 · · Score: 1

      Or make the bios completely independant of the operating system, where it runs in its own flash and memory so that it can update itself, but can not be updated by an external component. Do the same for the kernel, security key and password manager, and virus protection. Trully isolate the sensitive components in the system.

    21. Re:Hardware is trusted by NJRoadfan · · Score: 1

      UEFI uses a FAT32 partition with a special GUID on the hard drive to store boot loaders. Firmware settings have been stored in a battery backed CMOS for decades. There is no need for flash to store any of these settings.

    22. Re:Hardware is trusted by Kjella · · Score: 3, Insightful

      I think UEFI has two different tasks confused. One is to boot my OS, which should just involve pointing it to the right storage device and loading X bytes into memory. The other is to provide a system configuration environment where I can boot and other hardware settings and there I want a rich environment. I want to be able to use my USB mouse and Bluetooth keyboard in a GUI, wired and wireless drivers for PXE boot, storage and RAID drivers, you name it. Basically it is a little OS in itself, running off motherboard firmware.

      Now I have the impressions it's doing all this loading of a micro-OS with complex drivers only to finally hand over control to the real OS. Why? Maybe the OS wants to run a newer and better Bluetooth driver and now it can't because UEFI is running an old version. And if you do update the UEFI driver and break shit, you also broke your boot configuration. Just do the minimum requires to get the boot image, load it into memory and hand over control to the OS then get out of the way. If the boot fails, then you can launch the full configuration environment.

      --
      Live today, because you never know what tomorrow brings
    23. Re:Hardware is trusted by Anonymous Coward · · Score: 0

      One of the motherboards I have here requires a physical jumper be across 2 specific pins in order to effect a write to the BIOS.
      Something that should be standard on all MBs but for whatever reason, is not.

    24. Re:Hardware is trusted by Whiteox · · Score: 2

      (picking teeth) Ain't that what we called a bootstrap loader in my day?

      --
      Don't be apathetic. Procrastinate!
    25. Re:Hardware is trusted by Mryll · · Score: 1

      I don't know if it's that sinister. IIRC it was pretty standard practice to require a motherboard jumper change to enable updating BIOS. I think it was abandoned out of simplicity because users found it to be a pain in the ass.

    26. Re:Hardware is trusted by sumdumass · · Score: 2

      Most of the boards I am familiar with wouldn't allow a full boot if the jumper was enabled to flash. The nice thing was a recovery option where you could rename a bios extension, and it would load it automatically from the FDD. But as far as I know, it would stop the boot process if you left either setting jumped.

    27. Re:Hardware is trusted by Anonymous Coward · · Score: 1

      It would be easy to prevent such attacks by KISS as well. Sticking with something a lot more like BIOS instead of a multi-Megabyte EFI mess.

      In other words avoiding all that systemd embodies and assimilates.

    28. Re:Hardware is trusted by Anonymous Coward · · Score: 0

      At which point it's the user's fault for being an idiot instead of the manufacturer's fault for not supplying the tools to protect your bios from software attacks.

      At least you have the option of safety if the attacker requires physical access to fuck up your computer's bios.

    29. Re:Hardware is trusted by Lumpy · · Score: 1

      We only had a couple of skilled admins, all the rest were brain dead MCSE's that barely knew how to plug in power cords.

      But they were CHEAP! A lot cheaper than hiring people with actual skills and experience.

      --
      Do not look at laser with remaining good eye.
    30. Re:Hardware is trusted by lsatenstein · · Score: 1

      It'd be nice if the next iteration of EFI had a more robust upgrade security design.

      Something like this: Firmware upgrades are not possible from inside the OS. At all. Instead there's a switch on the mainboard that is only accessible when the computer has been physically opened. When that switch is on, EFI will refuse to boot any OS and all onboard SATA/SCSI controllers are physically disabled. EFI will scan every USB port* for a FAT32-formatted mass storage device containing a file with a certain filename, which is then displayed for your approval, checked and installed. While the switch is off, changing the firmware should be prevented in hardware, such as by detaching a certain line required to write to the flash chip. (Settings should be stored on an unprotected chip and can be changed while the computer is bootable.)

      You're in a corporate setting and need to update 16.000 identical desktop computers all at once? Make sure the computers have an enterprise-ready mainboard that can pull the update from the network (e.g. using something similar to BOOTP). You'll still have to toggle that switch and confirm the prompt. That's as convenient as it should get; after all, if there is any chance that the firmware is modified while an OS is loaded, any successful attack on the OS leaves your firmware in a potentially compromised state.

      * Yeah, I know, USB also has infectable firmware. Unfortunately, I don't know of a reasonable mass storage standard that doesn't. And making people physically swap PROM chips won't fly.

      Some, if not most mother boards have a slot or space for tpm chip. That tpm is a smart smart card chip that can store data, can encrypt data and act like a vault. Thats a few pennies and does not require an external pair of wires to a physical switch.
        TPM = Trusted Platform Module. ( http://en.wikipedia.org/wiki/T... )

      --
      Leslie Satenstein Montreal Quebec Canada
    31. Re:Hardware is trusted by sjames · · Score: 1

      I would be less worried about Secureboot if it was absolutely mandated to allow a user key and allow disabling. Alas, it hasn't been all that long and the one mandate out there (from MS) is now gone. It's interesting that it is supposed to be for the owner's benefit but typically doesn't offer a simple way for the user to bless a bootloader or OS nor does it offer a boot anyway option. Almost as if the benefit is meant for someone else.

      Perhaps the best approach would have been for the firmware to be just a simple bootstrap with a well-defined handoff to stage two which would reside in a seperately re-writable segment of the flash rom.

      That, in turn could do the rest of EFI or could be a more conventional bios or be replaced with SeaBIOS, bits of Coreboot, or whatever the user wants. I would expect the factory installed default to be a simple boot menu that can read MBR and GPT in order to load the disk based boot loader.

      That would both improve reliability where needed and make sure that you could always replace the offending EFI if it wanted to insist on SecureBoot or other potentially harmful scheme.

      Failing that, just go with the simplest possible bootstrap and let the OS or bootloader deal with the rest.

  2. Code reuse exacerbates the problem? by LazLong · · Score: 5, Insightful

    Manufacturers/vendors don't write their own BIOSs; they license them from the likes of Phoenix Technologies and Insyde. These licensors don't write a completely new BIOS and bits for each licensee, let alone for each motherboard and their variants. As such, of course there is code reuse. Imagine the probable security issues there would be if each Vendor, let alone motherboard, received a BIOS that was written from scratch. QA would be a nightmare, as would the security of the code.

    The problem isn't the reuse of code. The problem is that the code that was reused had security vulnerabilities.

    1. Re:Code reuse exacerbates the problem? by Anonymous Coward · · Score: 0

      Reusing code is like communism or GNULix.

    2. Re:Code reuse exacerbates the problem? by drinkypoo · · Score: 1

      The problem isn't the reuse of code. The problem is that the code that was reused had security vulnerabilities.

      If you have physical access to the machine, it doesn't matter. You can rewrite the BIOS. And then, yes, it is an advantage to malware authors if there's only a couple of kinds of BIOS, because their malware only has to support those kinds. So yes, reuse of code becomes a "problem" for the rest of us if viewed from that perspective. It's not clear though that life would be any better for users overall if there were more kinds of BIOS. As bad as Phoenix, Award et al can be at making BIOS that works, I shudder when I imagine vendors rolling their own. I'll live with the disease, thanks.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    3. Re:Code reuse exacerbates the problem? by Anonymous Coward · · Score: 0

      The notion of monocultures being bad also applies here. If everyone had written their own BIOS then it would be incredibly difficult with today's computing to infect a lot of them at once, even if they were buggy as shit.

      However, the days of this logic might be numbered... better SAT solvers might be able to drill through these kind of bugs in an automated fashion.

    4. Re:Code reuse exacerbates the problem? by LazLong · · Score: 2

      If you have physical access to the machine, it doesn't matter. You can rewrite the BIOS. And then, yes, it is an advantage to malware authors if there's only a couple of kinds of BIOS, because their malware only has to support those kinds. So yes, reuse of code becomes a "problem" for the rest of us if viewed from that perspective. It's not clear though that life would be any better for users overall if there were more kinds of BIOS. As bad as Phoenix, Award et al can be at making BIOS that works, I shudder when I imagine vendors rolling their own. I'll live with the disease, thanks.

      Yeah, I agree with with regards to the physical access vector. I have a background doing IT in a DOD TS/SCI environment for three years and a TS environment for eight with DOE. Our (those of use who knew what we were doing) had the philosophy that if you had physical access to a system then you could pwn it. AT DOE it wasn't our duty to design systems with any consideration of the "insider threat" unless it was for the use of FORNATs. Systems for US use relied mostly upon personnel and site physical security.

      I do disagree that a greater number of targets being more burdensome for the black hats outweighs the security benefits of supporting a smaller code base. The former is merely supposed security through obscurity. A basic rule of thumb of security is to minimize the attack surface. One of the primary strategies to accomplish this with regard to information security in a software environment is to reduce the amount of code running.

    5. Re: Code reuse exacerbates the problem? by Anonymous Coward · · Score: 0

      You think this or know this? Licensing isn't the same as contracting out. From what I've heard described, is they get an SDK licensed from award or phoenix, and do their own bios themselves.

      In recent weeks, someone on /. described how his group was competent and created the core files for a family of motherboards, and tested it well. It is then given to individuals who then customize it per the unique features for a given model. These individuals may be incompetent and rushed on time

  3. well shit by Anonymous Coward · · Score: 0

    I hope I have a business continuity plan. Do I?

    Let me ask my IT guy. Well shit, I fired the fucker for reading techie news on the job.

    Hold on, I'll phone India. Call someone! That always fixes everything.

    All I hear is laughter on the on the other end. Laughter and some kind of lively dance music.

    Well, shit.

  4. Terrible "Article" by txoof · · Score: 4, Informative

    The "article" is three paragraphs and a few quotes full of FUD. There's no real information in there; it contains no good suggestions as to how to check for or deal with bios infections. It takes three clicks to get to a site that actually has some of the research, but that's just a static page listing conference topics. Don't waste another minute on this nonsense.

    --
    This one's tricky. You have to use imaginary numbers, like eleventeen... --Hobbes
    1. Re:Terrible "Article" by Anonymous Coward · · Score: 0

      Perhaps we could instead find out where streams of the presentation might become available or even pdfs of the presentation instead of complaining.

      Anyway, I assume https://cansecwest.com/slides.html 2015 will be available sometime after the end of the conference. Anybody know if they upload video of the presentations anywhere?

  5. Didn't even have to do anything special by Anonymous Coward · · Score: 0

    We didn't even have to do anything special; we just had a kernel driver write an invalid instruction

    That kernel modules can wreck your system isn't exactly something new. How exactly does this invalidate good opsec (like disabling modules altogether or require them to be signed?).

  6. In Soviet Russia... by Thor+Ablestar · · Score: 2

    Soviet hackers have known something VERY similar for some time:
      https://xakep.ru/2011/12/26/58... (In Russian but you can try Google translation).

    1. Re:In Soviet Russia... by crunchy_one · · Score: 1

      An interesting article about Intel virtualization and the author's attempt to write a hypervisor.

  7. Your missing the point of this article by Anonymous Coward · · Score: 0

    You all dont have the aptitude or skills for critical thinking and are being hoodwinked by the misinformed press again.
    The critical information you have glossed over is that the problem is just and only UEFI bios that new supposedly super secure bios written by microsoft for every computer produced and used by gullible stupid idiotic hardware manufacturers. So the infection has now spread from windows and only windows to fucking the whole of creation because we live in a world full of fucking stupid dimwit idiots.

    1. Re:Your missing the point of this article by crunchy_one · · Score: 1

      EFI was actually invented and specified by Intel. The specification for UEFI, its successor, is maintained by a consortium of manufacturers.

      If you think UEFI is the baddest thing out there, check out SMM. It can be used to silently subvert any Intel-based machine going all the way back to some '386 parts.

    2. Re:Your missing the point of this article by Thor+Ablestar · · Score: 2

      Windows is only one of possible paths of BIOS infection. It may also be implanted by any of 3-letter agencies of your choice during a shipment or during a secret search, by bribed hardware vendor or by service processor that is included into some really cool servers (See "In Soviet Russia" above).

    3. Re:Your missing the point of this article by Anonymous Coward · · Score: 0

      This attack is not needed for those scenarios. If they can touch the systems with the appropriate equipment, they can in theory do a great deal of stuff without trying to go around the mechanisms to protect from software attacks.

  8. Right by Skiron · · Score: 1

    So you need admin and be able to install a dodgy kernel module to trash the machine. Then again, if you got that far, a 2lb hammer would suffice without needing to know anything about computers/kernels/modules.

    1. Re:Right by Anonymous Coward · · Score: 0

      I don't understand what you mean. Banging the machine with a 2lb hammer would be completely different attack. Are you really saying that if you can find some other way to attack the machine, then the possibility to rewrite the UEFI isn't a risk? You don't even need physical access to do it.

    2. Re:Right by Skiron · · Score: 1

      Well first you need to compromise a machine. Game over there and then, let alone starting to re-flash BOIS or whatever - this is just another *thing* that can be changed once you own the machine. No big surprise there.

      Of course, as to your question - if you have physical access (and a black hat), then game over anyway.

    3. Re:Right by Anonymous Coward · · Score: 0

      Right, but if this was protected, there would be less things to mess with. Especially when changes to UEFI code can be very hard to detect. It would be nice if I don't have to throw every compromised machine to trashcan, but can instead just reinstall the operating system.

    4. Re:Right by Skiron · · Score: 1

      "...but can instead just reinstall the operating system."

      Oh no, secure boot, remember. It isn't yours.

    5. Re:Right by Anonymous Coward · · Score: 0

      Bringing up Secure Boot is past the point here.

  9. In Soviet Russia, the Party can always find YOU! by Thor+Ablestar · · Score: 1

    Problem is NOT the trashed computer - you can simply buy a new one. Problem is that the 3-letter agencies can use this mechanism to covertly collect information about YOU, which may possibly land you in GULAG. And it seems it's quite difficult to detect this leakage.

  10. Ironically by Anonymous Coward · · Score: 1, Interesting

    The one company that got suckered into doing Superfish is also pretty much the one company that has an immune UEFI: Lenovo.

    Lenovo system x development actually writes their own firmware rather than going to AMI or someone. They also take directions from a very strict security team that has made them harden against this class of attack for years now (it wasn't a live vulnerability, but the general attack vector has been theorized for a long time).

    Of course, this is the system x team specifically (Servers that begin with x, Flex, BladeCenter, Nextscale) and not necessarily anything else (the part recently purchased from IBM). Although the aforementioned teams came along with the purchase and are starting to call the shots across all enterprise server development (though not necessarily business or consumer pcs/laptops).

    1. Re:Ironically by chill · · Score: 1

      And here is a link to the BIOS simulators (in Flash) for just about every Lenovo BIOS.

      http://service.lenovo.partner-management.com/et.cfm?eid=1437

      Here you can see BIOS settings and get familiar with the layouts. Not sure how helpful it is for security, but it is very informative.

      --
      Learning HOW to think is more important than learning WHAT to think.
    2. Re:Ironically by Anonymous Coward · · Score: 0

      Incidentally, the entirety of that list is *not* the system x lineup I talked about. Those are actually AMI sourced unlike the system x ones. Those firmware are more like what Dell, HP, et al use rather than being particularly special to Lenovo.

  11. Better link by Psychotria · · Score: 4, Informative

    http://conference.hitb.org/hit...

    Better apart from being a damn slideshow

    1. Re:Better link by crunchy_one · · Score: 1

      Bah to that. I prefer to have stories filtered through at least two poorly informed sources and then commented on by the clueless masses.

    2. Re:Better link by Anonymous Coward · · Score: 0

      Thanks for the link!

      It was my gut feeling all along: UEFI makes things worse for us, not better.

      It *could* increase security *if* implemented correctly, which in practice it's not. On the contrary, the usual industrial trend is to bury more and more code in SMM, which will increase instead of decreasing the failure rate "down there".

      So less security, more control of the end user by the corporate overlords. Disgusting.

      And -- Microsoft: we knew all along you were going to change your mind. Dirty scumbags.

  12. Re:In Soviet Russia, the Party can always find YOU by Lumpy · · Score: 1

    No it's trivial to detect the leakage. the packets have to go over the lan... Or are they reconfiguring the chips to become a quantum entangled radio?

    --
    Do not look at laser with remaining good eye.
  13. Re:In Soviet Russia, the Party can always find YOU by Anonymous Coward · · Score: 0

    No one has the time to monitor all the outbound traffic of their network interface.

  14. Unpatched BIOS by Anonymous Coward · · Score: 0

    Well, then, how the hell do I know that my BIOS is patched or not?
    Stupid article.

  15. Re:In Soviet Russia, the Party can always find YOU by Anonymous Coward · · Score: 0

    No one has the time to monitor all the outbound traffic of their network interface

    ... from a separate computer that you know hasn't been exploited.

  16. Re:Hardware is trusted by us at the NSA ... by BoRegardless · · Score: 1

    To allow us to hack your system, so don't change UEFI/EFI.

  17. Hustler by Anonymous Coward · · Score: 0

    So, mark, you are using SlashDot to drive traffic to your article on the issue? For shame.

    1. Re:Hustler by Anonymous Coward · · Score: 0

      [ ... Posting anonymously to save the mod I did on this page ... ]

      So Mark is using the submission to drive traffic to his own article at 'betanews.com', it seems. Interestingly, the Summary begins 'Mark Wilson writes' with the name linked to the /. user.

      Clicking through the user name link yields:

      'The user you requested does not exist, no matter how much you wish this might be the case.'

      Cue the Conspiracy Crowd.

  18. Not new by fred911 · · Score: 1

    Seeing how the the article is so dense with real content and references, what makes this different from CIH http://en.wikipedia.org/wiki/CIH_computer_virus ?

      This infection was sometimes a real bitch to fix as you had to hunt for the exact bios for the device (which wasn't an easy task), remove the eeprom and flash it. An real PITA and one that Joe Sixpack couldn't fix. A real nasty infection.

    --
    09 F9 11 02 9D 74 E3 5B - D8 41 56 C5 63 56 88 C0 45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
    1. Re:Not new by Thor+Ablestar · · Score: 1

      I have repaired a CIH long time ago. I installed an UV EPROM instead of Flash. There was a problem: Each time the computer booted up, it checked the saved config, reported an error and rebuilt the config. It took time but at least it worked. I believe the modern config is too big for this hack.

  19. as always... by steak · · Score: 1

    physical access = game over. when this can be spread remotely, then I'll start freaking out.

    --
    lose != loose
  20. Not physical access.. by Anonymous Coward · · Score: 0

    It requires administrator privilege, but not physical access.

    So if youir remote exploit opens the door to running arbitrary code, and then you can do something like rowhammer to co-opt the administrator privilege of an existing process, you can load kernel code that can do the appropriate manuevers and modify the system firmware forever, with the only recourse generally involving a soldering iron or throwing out the board.

    1. Re:Not physical access.. by Skiron · · Score: 1

      "that can do the appropriate manuevers"

      Was that supposed to be "manual levers"?

  21. UEFI or UFIA by goombah99 · · Score: 1

    Somehow I always get these two mixed up.

    http://www.urbandictionary.com...

    --
    Some drink at the fountain of knowledge. Others just gargle.
  22. That's nothing... by Anonymous Coward · · Score: 0

    ...Two minutes is all it takes to completely destroy a computer....

    I've got a grenade that can do it in 8 seconds...

  23. Complete list of affected manufacturers/vendors? by rnturn · · Score: 1

    Has anyone gotten a hold of a complete list of the manfacturers/vendors whose products are affected by this? The way this has been worded there are more than the five mentioned in the summary text. Have products from any vendors been found to be "safe". (At least, so far?) And what versions of BIOS have been found to be vulnerable?

    --
    CUR ALLOC 20195.....5804M
  24. How do I load my keys? by Anonymous Coward · · Score: 0

    My Dell will not upgrade from 8.1 to 8.1 Professional. Microsoft has not even been able to solve the problem, though they validated my keys. The problem is Secure Boot / UEFI on the Dell. What kind of benefit is it to me when my computer will not accept legitimate updates?

  25. between this, secure boot and everything else... by Anonymous Coward · · Score: 0

    sounds like uefi was an awesome idea. give me write-switch-protected cmos bios any day.

  26. The slides are finally posted by BIOS4breakfast · · Score: 1

    Maybe now people can have *informed* opinions? Slides here: http://legbacore.com/Research....

  27. Enough info to get the idea. by Anonymous Coward · · Score: 0

    The "article" is three paragraphs and a few quotes full of FUD. There's no real information in there; it contains no good suggestions as to how to check for or deal with bios infections. It takes three clicks to get to a site that actually has some of the research, but that's just a static page listing conference topics. Don't waste another minute on this nonsense.

    There is information buried in there:
    "We didn't even have to do anything special; we just had a kernel driver write an invalid instruction to the first instruction the CPU reads off the flash chip, and bam, it was out for the count, and never was able to boot again."

    In other words "Lighteater" is another name for flashing a bad BIOS (or part thereof). People have bricked their machines doing this by accident. Many modern BIOSes have some kind of checking on the BIOS update program. This is just a malicious one that bricks your machine on purpose. In theory it could be made to install spyware at BIOS level though I don't see that having been demonstrated.