Slashdot Mirror


First-Ever UEFI Rootkit Tied To Sednit APT (threatpost.com)

Researchers hunting cyber-espionage group Sednit (an APT also known as Sofacy, Fancy Bear and APT28) say they have discovered the first-ever instance of a rootkit targeting the Windows Unified Extensible Firmware Interface (UEFI) in successful attacks. From a report: The discussion of Sednit was part of the 35C3 conference, and a session given by Frederic Vachon, a malware researcher at ESET who published a technical write-up on his findings earlier this fall [PDF]. During his session, Vachon said that finding a rootkit targeting a system's UEFI is significant, given that rootkit malware programs can survive on the motherboard's flash memory, giving it both persistence and stealth.

"UEFI rootkits have been researched and discussed heavily in the past few years, but sparse evidence has been presented of real campaigns actively trying to compromise systems at this level," he said. The rootkit is named LoJax. The name is a nod to the underlying code, which is a modified version of Absolute Software's LoJack recovery software for laptops. The purpose of the legitimate LoJack software is to help victims of a stolen laptop be able to access their PC without tipping off the bad guys who stole it. It hides on a system's UEFI and stealthily beacons its whereabouts back to the owner for possible physical recovery of the laptop.

168 comments

  1. Slashdot by Anonymous Coward · · Score: 0

    Bringing you September's news, today!

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

      Haha I saw a couple of these documented today, along with surveys asking for a ranking of the threats from high to low. I usually just click the default option since I donâ(TM)t know the answers and smile. Speaking of vulnerabilities, I told a fanboi that Apple was not really secure and then I realized that he wasnt including user-downloaded warez that are also malware in other contexts. Never would have occurred to me in a million years they call that malware. I will stop contradicting them

    2. Re:Slashdot by mnemotronic · · Score: 1

      Bringing you September's news, today!

      +1

      --
      The Russians have won. They have made the world a cesspool of distrust, greed, fear and hate.
  2. Phishing email or equivalent? by AHuxley · · Score: 2

    Still have to have that human interaction with a click.
    How long until this can be pushed down direct from a website?

    --
    Domestic spying is now "Benign Information Gathering"
    1. Re:Phishing email or equivalent? by Anonymous Coward · · Score: 0

      The UITest Framework could be tainted and deployed in a way to automate a consented installation of malware?

    2. Re:Phishing email or equivalent? by Anonymous Coward · · Score: 0

      Also, I know an IT clerk working in Palo Alto who must be having wet dreams about persisting his amazon cookie there.

    3. Re:Phishing email or equivalent? by Anonymous Coward · · Score: 0

      Still have to have that human interaction with a click.

      How long until this can be pushed down direct from a website?

      likely sometime in 2019

      a rootkit inside a rootkit.. how meta.. just like windows 10

    4. Re:Phishing email or equivalent? by thegarbz · · Score: 1

      How long until this can be pushed down direct from a website?

      Is this even relevant? The human flaw in the security model is one that we've shown for the past 20 years can't be patched. I'm surprised anyone is looking for automated methods anymore when you can just pretend to be Paypal saying there's a problem with your account.

    5. Re:Phishing email or equivalent? by EndlessNameless · · Score: 1

      How long until this can be pushed down direct from a website?

      Just wait for the next browser-based arbitrary code exploit. There are usually several disclosed and patched per year.

      If we consider undisclosed ACEs, then it could be happening already.

      --

      ---
      According to the latest ruleset, this post should be modded as Vorpal Flamebait +5.
    6. Re:Phishing email or equivalent? by AHuxley · · Score: 1

      Automated methods stop that one person who just has to report that email.
      Also email is often easy to scan by AV software.

      --
      Domestic spying is now "Benign Information Gathering"
    7. Re:Phishing email or equivalent? by thegarbz · · Score: 1

      Also email is often easy to scan by AV software.

      I think you're confused. The Email does not contain the malware. AV software does nothing to stop idiot users from taking very careful aim while shooting themselves in the foot.

    8. Re:Phishing email or equivalent? by AHuxley · · Score: 1

      That strange link has to be presented in some way. That can be detected.

      --
      Domestic spying is now "Benign Information Gathering"
    9. Re:Phishing email or equivalent? by thegarbz · · Score: 1

      That can be detected.

      If you can do that you could make a shitton of money in the security game. Every security product on the market scans emails, yet phishing is still trivial and incredibly effective.

  3. APT? by Anonymous Coward · · Score: 1

    What is an "APT" in this context? Even the original article doesn't explain it. Does nobody think about proper editing any more?

    1. Re:APT? by Fly+Swatter · · Score: 5, Informative

      Yea, a definition would be quite apt here: Advanced Persistent Threat. (per wikipedia APT)

    2. Re:APT? by Anonymous Coward · · Score: 0

      Sadly, because of the way MS designed UEFI, this is completely un-patchable
      except by throwing out the hardware and purchasing a new computer. Period.
      UEFI has been nothing but an embarrassment to MS and Billy. All of this was
      predicted and the exploit demonstrated to Billy, but he was unwilling to listen.

      CAP === 'fraction'

    3. Re:APT? by Anonymous Coward · · Score: 0, Insightful

      Not knowing what an APT is in context of infosec is like not knowing what a CPU is while reading programming news.

      It's expected the audience will know the basics.

    4. Re:APT? by Anonymous Coward · · Score: 0

      What does Debian's and Ubuntu's advanced package tool have to do with Windows or UEFI?

    5. Re:APT? by Anonymous Coward · · Score: 1

      UEFI is due to Intel, not MS

    6. Re: APT? by Anonymous Coward · · Score: 0

      That is because MS cannot support all the settings intel provides. I believe they are working to align the critical settings in an orderly way

    7. Re:APT? by AHuxley · · Score: 1

      Things that live in what was the "BIOS" that can stay ready.
      The user can swap new storage, reinstall, OS all they like.
      Wonderful fun for police/gov malware and the security services.

      --
      Domestic spying is now "Benign Information Gathering"
    8. Re:APT? by ArchieBunker · · Score: 1

      Like the Linux kernel talking about DRM. Digital Rights Management or Direct Rendering Manager? Clear as mud.

      --
      Only the State obtains its revenue by coercion. - Murray Rothbard
    9. Re: APT? by Anonymous Coward · · Score: 0

      Aham, no. You can reprogram the flash chip with a raspberry pi (on a computer you can open - so no surface.

    10. Re:APT? by Anonymous Coward · · Score: 0

      We need a UEFI report status and Clear' utility. No exceptions no BS.
      Well now we have a base malware, that can probably do this.
      I have a UEFI that wont let me load my own pad driver, preventing windows7 from working - but fine under Win10. Probably *nix as well.
      Intel is unlikey to do a mass recall for models older than 3 years.

    11. Re:APT? by Anonymous Coward · · Score: 1

      Linux+APT. Package manager.

      Rootkit+APT. Advanced persistent threat.

      Address+APT. Apartment number.

      This is how human beings learn meaning through context. It's a skill the few who lack it naturally pick up around second or third grade.

    12. Re:APT? by Anonymous Coward · · Score: 0

      Surprised this wasn't modded funny... a definition would be "apt". LOL! Well done!

    13. Re: APT? by Zero__Kelvin · · Score: 1

      It's s term people who actually belong on Slashdot understand because when it first started appearing here years ago we knew how to google it.

      --
      Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
    14. Re: APT? by Anonymous Coward · · Score: 0

      Stop trying to finagle yourself into being right. You're not. UEFI is Intel's baby, built to boot faster than BIOS and support newer tech.

    15. Re:APT? by prisoner-of-enigma · · Score: 1

      Clear as mud.

      It's spelled MUD and what do Multi-User Dungeons have to do with a security thread you insensitive clod???

      --
      In the end they will lay their freedom at our feet and say to us, Make us your slaves, but feed us. - Fyodor Dostoyevsky
    16. Re: APT? by squiggleslash · · Score: 1

      I've been on Slashdot since the 20th Century, and to be honest this is the first time I've seen those letters with this definition. You can kinda figure it out from context, but no, software developers are unlikely to run into this phrase during our day to day work.

      --
      You are not alone. This is not normal. None of this is normal.
    17. Re: APT? by Zero__Kelvin · · Score: 1

      Nice anecdote. The fact remains that on Slashdot there is no need to define APT in computer security story summary since it is by no means a new term and has appeared on Slashdot hundreds of times, just as there no need is to define CPU in a hardware story. If you haven't heard of it because you missed all those earlier stories for some reason then you google it, rather than polluting the comment section with complaints that you are both ignorant (of the term) and too lazy to type it into your search box.

      --
      Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
    18. Re:APT? by ls671 · · Score: 1

      Well, you seem really apt in the matter, dear sir!

      --
      Everything I write is lies, read between the lines.
  4. So... by Anonymous Coward · · Score: 0

    UEFI isn't a rootkit immuniser. Funny, that.

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

      Blame Intel.

      Ideally the UEFI canâ(TM)t be flashed unless the user confirms it. The problem is that users are trained to click ok on security prompts. In enterprise environments users will ignore error messages with the assumption that IT will be notified automatically.

      Like on Dell machines to update the TB3 firmware, or the docking station firmware, if the TB/USB3 drivers arenâ(TM)t new enough, bricks the entire USB3 subsystem. That requires resetting the CMOS.

      What would solve this would be to have the Bios reject firmware changes without a USB drive attached with both the old and new bios on it the first time. Basically to change the firmware, the PC would detect UEFI changes and check if the USB drive contains the previous version. If not it would boot the backup firmware and treat the UEFI as tainted.

    2. Re:So... by AHuxley · · Score: 1

      Did not keep Linux from booting. Now its open to strange new rootkits too.

      --
      Domestic spying is now "Benign Information Gathering"
    3. Re: So... by Anonymous Coward · · Score: 0

      Blame Intel.

      redmond certainly had a big fat hand in it, so blame both. Both are idiot companies that time and again come up with idiot designs that are more dangerous than that they do actual useful work. So it fits.

      Ideally the UEFI canâ(TM)t be flashed unless the user confirms it.

      A jumper on the board would do that, and restrict upgrades to people who know at least the basics of hardware maintenance.

      (For most people that means having the local fly-by-night hardware shop do it, even though actually doing it is dead easy... if you know how. And why not? If they fuck up, and idiot lusers are very good at that, they'll end up there anyway, but now the shop needs a jtagger, spi programmer, or chip-puller and eprommer, to fix the damage.)

      The problem is that users are trained to click ok on security prompts.

      Trained by... redmond, mostly. Though intel helped, of course.

      In enterprise environments users will ignore error messages with the assumption that IT will be notified automatically.

      Like on Dell machines to update the TB3 firmware, or the docking station firmware, if the TB/USB3 drivers arenâ(TM)t new enough, bricks the entire USB3 subsystem. That requires resetting the CMOS.

      What would solve this would be to have the Bios reject firmware changes without a USB drive attached with both the old and new bios on it the first time. Basically to change the firmware, the PC would detect UEFI changes and check if the USB drive contains the previous version. If not it would boot the backup firmware and treat the UEFI as tainted.

      That is a lot of arbitrary and picky complexity to "fix" the problem of "updating" already terminally broken badness. Several layers of terminally broken idiot badness.

      This is a common theme in peecee-land.

      Like your broken apostrophes. You could've had your broken software use ASCII single quote marks instead of unicode extra special reinventions of same. Don't blame /. here now, it supports unicode but because /.ers had a field day abusing the idiocy in unicode (and it has a lot of that built into it) the thing got turned off again. This has been the case for years, so you've had plenty of time to beat your crap software into submission.

      Likewise intel and redmond could have come up with something sensible, they just chose not to. Alright, some other company might have done that, I'll grant that intel and redmond are probably incompetent at sensible design. We still give our money to them for some reason. Meaning that the market isn't rational and so capitalism isn't functioning as it should since it requires those absent rational actors to function properly.

    4. Re: So... by TheRaven64 · · Score: 2

      A jumper on the board would do that, and restrict upgrades to people who know at least the basics of hardware maintenance.

      The firmware is right at the root of your trusted computing base. If you require opening up the case and moving a jumper in every machine to push out an update, then most people are never going to do it. This means that, if there's a security vulnerability then it will never be patched for 95% of users. Given that BIOS vendors are responsible for some of the worst code in production, which is often able to be attacked over the network or via USB, do you really think that this would improve security?

      --
      I am TheRaven on Soylent News
    5. Re: So... by Anonymous Coward · · Score: 0

      Most people only have the one, so "every machine" equals "one machine". And as already argued, if it's too hard have someone qualified do it. That is what happens now (or doesn't, leaving the peecee unmaintained) anyway, plus malware that circumvents the software trickery then installs itself in that space previously protected by that one jumper.

      Even with the software trickery that fails to adequately replace the one jumper but has some nasty side effects, the updates often end up NOT getting applied anyway. And no, the trickery is no fix against bad code. So if it's really a problem the BIOS vendors will just have to up their game and write better code. That requires A LOT less work from A LOT of UNQUALIFIED people to "fix up" after the idiot BIOS vendors with "updates" from same idiot BIOS vendors.

      The jumber closes a bad code nestling hole, doesn't inconvenience "professional home peecee maintainers" much, as in the yearly check-up that starts with blowing out all the dust and pet hairs anyway, and in fact would sooner trigger unqualified people to ask a qualified person to help them with something they don't understand and would prefer not to have to do themselves anyway.

      So YES REALLY the jumper is the safer option for typical home peecee use.

      But it goes against the grain for idiot developers who want to fix everything in software, even if it can't be done.

      Of course, for big large "warm body", "enterprise" shops where a small army of windows "admins" use WOL to "update" "seats" at night, well, the desktop peecee is a poor fit there anyway. Hence things like "thin clients", citrix, and so on.

    6. Re: So... by TheRaven64 · · Score: 1

      Most people only have the one, so "every machine" equals "one machine".

      No, one machine per person equals a number machines equal to the number of people, not one.

      Most people only have the one, so "every machine" equals "one machine".

      No it isn't. Now, BIOS updates are pushed out as part of Windows Update for the majority of computer users. Apple pushes out UEFI updates as part of macOS updates, and I believe a couple of Linux vendors do so as well.

      --
      I am TheRaven on Soylent News
    7. Re: So... by prisoner-of-enigma · · Score: 1

      I'll take you one step further: in a corporate environment with thousands of PC's this would be effectively impossible. Right now there are tools to mass-deploy BIOS updates. Throw a physical requirement into the mix and all that becomes useless.

      --
      In the end they will lay their freedom at our feet and say to us, Make us your slaves, but feed us. - Fyodor Dostoyevsky
  5. Just one more reason... by Anonymous Coward · · Score: 0

    Just one more reason that UEFI is a BAD BAD IDEA!!!!!!!!!!

  6. Not Windows! by Anonymous Coward · · Score: 0

    It has extra-super-secure technology. Why do people keep deifying that company? They're in it for the money; they're just more transparent about it. If you want their junk buy it, be happy, and move on. But stop the genuflecting already.

    1. Re:Not Windows! by Anonymous Coward · · Score: 0

      why do people keep deifying microsoft
      That the strawman you wanna go with? Alright, have at it, tell "those people" they're dumb to do so.

  7. Hijack is Whack by mentil · · Score: 1

    Lojack got jacked by jackoffs so they can hijack you from the back without even using JTAG.

    --
    Corruption is convincing someone that the selfless ideal is the same as their selfish ideal.
    1. Re:Hijack is Whack by Anonymous Coward · · Score: 1

      Get back, Jack, do it again.

    2. Re:Hijack is Whack by Aighearach · · Score: 1

      Exactly, and worse, they smell like cigarettes and vodka.

  8. Infected by Anonymous Coward · · Score: 0

    I wonder why my computer wanted to update UEFI when i rebooted it today...hm

  9. Whatever happened to... by Anonymous Coward · · Score: 2, Insightful

    Whatever happened to requiring the insertion of a jumper on the motherboard to update the BIOS? That would stop this thing in its tracks.

    1. Re:Whatever happened to... by Fly+Swatter · · Score: 2

      Now don't go spouting things like common sense to manufacturers. This is the 21st century after all.. Also I was under the impression that many UEFI BIOS like to write to itself for settings and note taking (sigh) within the bios screen etc. That would require TWO flash chips so that one could be made write protected with a hardware jumper (hey those things are expensive).

    2. Re:Whatever happened to... by sjames · · Score: 5, Insightful

      This. Unlike old BIOS that only needed a few bytes to maintain configuration (commonly battery backed CMOS, but eeprom could be used) the latest abomination from Intel needs a full fledged read/write flash file system. To make it worse, unlike old BIOS where clearing the CMOS would recover from any mis-configuration, some implementations of EFI can be bricked.

      Now, from TFA, it turns out UEFI makes a dandy platform for persistent malware.

      So, NOW can we go back to BIOS and just make it unstand GPTs?

    3. Re:Whatever happened to... by AHuxley · · Score: 1

      Replaced by USB to flash/back up and a big bright color led.

      --
      Domestic spying is now "Benign Information Gathering"
    4. Re:Whatever happened to... by sfcat · · Score: 1

      Mod parent up

      --
      "Those that start by burning books, will end by burning men."
    5. Re:Whatever happened to... by ctilsie242 · · Score: 1

      Physical attestation, or just a way to check that there is a layer 8 presence, can go a long way when it comes to security. This is why Google went with a Yubikey-like setup internally, since malware would have to get the user to physically jam in their physical device and hit the button to work for every action.

      I wonder how this can be done in modern times. Perhaps repurpose the "Turbo" switch into a "firmware updates allowed after next power cycle" mode, where firmware stuff can happen when the button is pressed... but it requires a full power cycle to do so. This is similar to how ATA password protection commands are locked out on bootup to ensure some rogue program can't lock the HDDs, then demand a random notice.

    6. Re:Whatever happened to... by Anonymous Coward · · Score: 0

      While we're at it, why don't all USB flash drives have a write-protect switch? The flash chips have a /WE line, so it's not difficult. Manufacturers are just lazy and cheap.

    7. Re:Whatever happened to... by Anonymous Coward · · Score: 0

      It does require the insertion of a jumper. It is just not a "physical" thing anymore because then the designer would not be in control of the jumper -- the one in physical possession of the jumper would be in control, and this is not how the system was designed.

      A certain bit must be set to 1 in order to be able to write to the BIOS.

      You, however, are not BY DESIGN, in control of whether the jumper is installed (set) or not (clear). You are however free to DESIGN and BUILD your own systems where YOU are in control of the jumper. You have just simply chosen to by a system designed by where wanted to be in control of the jumper -- that is, the failure to maintain control is YOUR negligence, not anyone else's.

    8. Re:Whatever happened to... by Anonymous Coward · · Score: 1

      Haha, no. Current UEFI systems are internet enabled and even come with shell environments capable of running custom scripts.

      The very few which have gained the attention of security researchers have had zero authentication and some have had always-running services which have been exploited in testing environments. Go search Mitre for CVEs.

    9. Re:Whatever happened to... by Anonymous Coward · · Score: 0

      Enabled processor TMP also prevents updating BIOS, at least for the motherboard tools. I wonder if the Windows firmware update device, which I assume is the problem here, can somehow circumvent that limitation.

    10. Re:Whatever happened to... by nateman1352 · · Score: 4, Interesting

      As someone who writes BIOS for a living, no we can't go back to legacy BIOS at this point. Chipset initialization has gotten too complex to fit in the 1 MB of RAM allowed by 16 bit real mode. UEFI is actually a big upgrade for firmware engineers since it natively supports the C language and 64 bit long mode. None of the silicon released by Intel or AMD in the last 5 years would be bootable with 1 MB of RAM.

    11. Re: Whatever happened to... by Anonymous Coward · · Score: 0

      Additionally, there have been bios malware

    12. Re:Whatever happened to... by Anonymous Coward · · Score: 0

      This does not mean that UEFI is the only possible way forward or that it exonerates its idiot design, its obvious flaws, and its assault on ownership. And, you know, nobody says that chipset initialisation must be complex. It's just that this happens to be the case and instead of reducing the complexity, "yo dawgs" threw more complexity at the complexity to hide the complexity in the complexity. Well done, idiots.

    13. Re:Whatever happened to... by benjymouse · · Score: 1

      Whatever happened to requiring the insertion of a jumper on the motherboard to update the BIOS? That would stop this thing in its tracks.

      The jumper (which only a few motherboards ever featured) has been replaced with a digital signature. Secure Boot stops this thing in its track.

      The summary conveniently skips arguably one of the most important takeaways from TFA:

      By enabling Secure Boot, and making sure their UEFI firmware is up to date, end users can protect themselves against attack, Vachon said.

      --
      Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
    14. Re: Whatever happened to... by Anonymous Coward · · Score: 0

      Any thoughts or suggestions on how the current system might be improved and secured

    15. Re: Whatever happened to... by Anonymous Coward · · Score: 0

      Throw it out and start over. For starters, ditch the requirement to "make it look all shiny, just like windows!" And so on.

      Also, an IDC 16bit FORTH easily yields smaller code than assembly(!), so you'd have to really work at it to make it be unable to initialise reasonably sane chipsets in that magic 1 MB space. This does not mean I'm advocating sticking to real mode. The comment is there to show that the argument "oh noez we're out of space" is probably bunk, or caused by poor judgement (idiot chipsets) or murky intentions (fucking over the owner and calling it "security"). Toss out some of the gunk and junk and presto, plenty of space. There's plenty of crap in BIOS, even more in UEFI.

      The real problem will be all the other stuff besides "boot up, load OS" that they wanted in there, like graphics support, "secure boot", "hardware" that requires to be fed blobs before it'll function, and generally unsanitary practices requiring lots of libraries, size-pessimized "C/C++ support", and so on. Even "loading OS" went from "load the first sector from the first disc, run it, done" to, er, lots of complexity that really doesn't buy us much but does require OSes to bend over backwards to accomodate all that shit. This actually is a boon for exactly one OS, the one that did exactly that in that way already. All the rest now has to make like that one OS from that one vendor, regardless of what they used to do before.

      As to "securing", you'll have to explain what you mean by that. The manufacturers (intel+redmond+big entertainment) want to make sure the machine only runs code they approved and they want to be able to check this from a distance. This simply does not make sense for owners of general computing devices, since someone else now controls what they can and cannot run on the hardware they thought they owned. Yet this is exactly what "secure boot" does -- it does not make end-users or end-owners more "secure", it constricts them. It also doesn't really prevent malware, as we've seen a few times before. The best readily available defense against malware is to run operating systems that don't drop their pants so much.

      Basically any OS not from redmond is a step up in this regard. And yet UEFI nudges you towards it already, but "secure boot" tends to lock you into running only redmond-originated (or at best -approved; would you trust a code vendor's judgement on code quality that cannot produce good quality code to save their lives?), so it pulls you down into misery.

      So I ask you directly: Just what do you mean with "securing"?

    16. Re:Whatever happened to... by UnknownSoldier · · Score: 2

      > Chipset initialization has gotten too complex to fit in the 1 MB of RAM

      8-bit machines only need a few KB for this. WTF are you guys doing that you need more then 1024 KB ???

    17. Re:Whatever happened to... by sjames · · Score: 4, Interesting

      As another (former) BIOS writer, why not pop it into flat-32 and go from there? Implementing a complex API complete with a file system seems a bit much for something that will run just long enough to call a boot loader.

      IIRC, a number of BIOS do, in fact, go into flat-32 mode. The big catch to using C is not the size of the flash chip, it's the need to have space for the stack before you get memory up. That is handily solved by configuring the CPU to use it's cache as a temporary RAM long enough to get the actual RAM up.

      CoreBOOT + SeaBIOS manage to be implemented mostly in C and work just fine. Most server boards still manage to implement "Legacy boot mode".

    18. Re: Whatever happened to... by sjames · · Score: 4, Interesting

      Unfortunately, UEFI appears to be insecure by design. So, step one, shred UEFI and secure wipe it's source.

      CoreBoot has a nice modern design that works. The only thing holding it back is lack of vendor support.

      A minimalist extension of the old BIOS system to go to flat 32 bit mode ASAP, and load a bootloader the same way old BIOS does comes to mind. If necessary, expand the CMOS a bit, but under no circumstances allow it to contain code, just settings. And like the old BIOS, if the CMOS doesn't pass a checksum, write sane defaults to it. Writing to the flash should never be needed for normal operation, write should need to be enabled ONLY if a BIOS update is needed, and that should be a very rare event.

      A wishlist item is that all of the "secret sauce" that requires vendor support and NDAs should be packed into one section and when it is complete, it should simply jump into a well known location to take care of loading the boot loader. Do NOT implement a memory allocator, filesystem, word processor or Eliza in BIOS. Rule 1, the system must operate normally if writing to flash is disabled.

    19. Re:Whatever happened to... by vbdasc · · Score: 1

      As someone who writes BIOS for a living, no we can't go back to legacy BIOS at this point. Chipset initialization has gotten too complex to fit in the 1 MB of RAM allowed by 16 bit real mode.

      Please forgive my ignorance, but how about the Unreal mode, that can give you the full 4GB of RAM? It's well known, universally supported and used for almost 3 decades now.

    20. Re: Whatever happened to... by Tom · · Score: 1

      Yet this is exactly what "secure boot" does -- it does not make end-users or end-owners more "secure", it constricts them. It also doesn't really prevent malware, as we've seen a few times before. The best readily available defense against malware is to run operating systems that don't drop their pants so much.

      As a security professional, I am a big fan of the concept of secure boot - not necessarily current implementations. The purpose of secure boot is to give me a known secure state of the system. I want that you can't drop some shit somewhere that will run underneath my ring 0 because it gets loaded first. If the boot process can ensure that my kernel gets loaded and handed control of the system, then I can be responsible from that point on and use RBAC or SELinux or OpenBSD secure levels or whatever to stay in control. But if some shit pre-empts me and puts itself between my kernel and the hardware, nothing I do matters.

      I much prefer Coreboot over UEFI for the same reason - control.

      --
      Assorted stuff I do sometimes: Lemuria.org
    21. Re: Whatever happened to... by Anonymous Coward · · Score: 0

      CoreBoot has a nice modern design that works. The only thing holding it back is lack of vendor support.

      Sadly, this doesn't appear to be the case. That is, yes, vendor support is holding it back. But it's not the only thing holding it back. Their website just gives me a blank page. So to me they're entirely dead and I can't even check if any of the hardware I have is supported. I recall from years ago when it didn't do that, the website was a bit of a jumble, too much of a big bag of snippets of notes only useful to domain experts, and just about no material to become such a person. I write C and x86 assembly well enough, but even so the thing didn't look enticing.

      So I think coreboot should get their collective head out of their collective ass. It'd be great if there'd be more support, better documentation, better up-to-date information as to what works and how to make it work, perhaps a config generator or even a binary generator to get started: Something like feed it your lspci/pciconf output and get a working binary back. That takes far more than the tinkering shop it was, and even more than the norwegian blue parrot it is now.

      And as for libreboot... well, the lead went full social justice retard, so we can write that off as a serious option too.

    22. Re: Whatever happened to... by Anonymous Coward · · Score: 0

      coreboot website looks fine to me, looks like it's your problem

    23. Re:Whatever happened to... by Anonymous Coward · · Score: 0

      "unstand"?

    24. Re:Whatever happened to... by AmiMoJo · · Score: 1, Informative

      Because UEFI doesn't just call the bootloader. It implements stuff like Secure Boot, the ability to run platform independent expansion card firmware (EFI, which uses a virtual machine to make it CPU architecture agnostic), CPU microcode updates, reading XMP data for RAM configuration etc.

      In many ways it does less than the BIOS, not bothering to do a full init on most of the hardware or provide any APIs for it, which is why boot times are better. But it does have to provide some important security functionality at the very minimum, which prevents most rootkits from working (including this one).

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
    25. Re:Whatever happened to... by houghi · · Score: 2

      And it us unpossible to write a BIOS in anything but 1MB chips, e.g. in 2MB or 640MB chips?

      I now have some sort of BIOS, that tries to do everything, so I can run a bootloader, that tries to do everything, so I can launch a destop manager, that tries to do everything, to have a browser, that tries to do everything visit a page, that tries to do everything.

      --
      Don't fight for your country, if your country does not fight for you.
    26. Re:Whatever happened to... by grimr · · Score: 1

      The purpose of unreal mode was to access more memory while still being able to quickly call real mode DOS/BIOS services and device drivers. Since in this case it is the BIOS and you have to go into protected mode to set up unreal mode, might as well just stay in protected mode and access all of memory that way.

    27. Re:Whatever happened to... by thegarbz · · Score: 1

      Unlike old BIOS that only needed

      to do very little, UEFI is complex due to the nature of increased complexity of our computer systems.

      To make it worse, unlike old BIOS where clearing the CMOS would recover from any mis-configuration

      "Configuration" cal also be cleared by clearing the CMOS.

      some implementations of EFI can be bricked.

      BIOSes could happily be bricked too. The only reason that it didn't happen more often is that Windows prevented the low level hardware access needed to write to it. Incidentally this also caused big problems for updating or recovering the system if needed.

      it turns out UEFI makes a dandy platform for persistent malware.

      Any platform could be used for persistent malware. The only reason the old BIOS wasn't is because it was too small. Incidentally there's a long list of viruses from the 90s and early 00s that did modify / corrupt the BIOS, and there's nothing more persistant than owning a large beige paperweight. Also many viruses used the static requirements from the old BIOS to become persistent and we even used to say that boot sector viruses worked at the "BIOS level" in the past for this very reason.

      So, NOW can we go back to BIOS and just make it unstand GPTs?

      If you knew anything about UEFI and BIOS, you'd know the answer to that is a resounding no. If you think that GPTs is what separates the modern UEFI and the older BIOS in terms of minimal functional requirements to operate your computer then my friend you have some learning to do.

    28. Re:Whatever happened to... by thegarbz · · Score: 1

      > Chipset initialization has gotten too complex to fit in the 1 MB of RAM

      8-bit machines only need a few KB for this. WTF are you guys doing that you need more then 1024 KB ???

      8bit machines had CPUs where you could count the transistors by hand without making a mistake (8080 had 3500 transistors). My current CPU has over 4billion. You may have noticed computers have gotten more complex.

    29. Re:Whatever happened to... by sjames · · Score: 3, Interesting

      Those functions (when wanted) should be provided by a bootloader like object that gets loaded by the BIOS. So far, the biggest use of secure boot seems to be making sure your computer doesn't do things you want it to if the *IAA don't want it to.

      Meanwhile, other architectures don't use EFI and I see no signs that any want to, so that makes platform independant boot ROMS a bit pointless. If wanted, that could be bolted on as well.

    30. Re: Whatever happened to... by sjames · · Score: 1

      Seconding the other AC, the page comes up for me. I'm still on the mailing list and it looks to be quite active.

    31. Re:Whatever happened to... by sjames · · Score: 1

      understand

    32. Re:Whatever happened to... by sjames · · Score: 2

      The correct way to protect the BIOS is a jumper that has to be set to enable writing/erasing the flash. End of story.

      The old BIOS already managed to init the CPU, init the memory controller, init the memory, and provide enough setup of PCI devices to find the boot loader or jump to PXE.

      I have actually written boot firmware. Most of those complex things beyond what I mentioned above are complex because they don't belong in the boot firmware at all.

    33. Re:Whatever happened to... by AmiMoJo · · Score: 2

      That's basically what happens, the UEFI loads the Secure Boot module which then verifies the boot files. Obviously the Secure Boot module has to be in the UEFI where it can't be modified by malware, or it wouldn't work.

      It's widely used to prevent infection by rootkit. By validating the OS boot files with a public key they can't be modified by a rootkit.

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

      Along with CPUs that don't run secret processes like a management engine, which also can be exploited.

    35. Re:Whatever happened to... by Anonymous Coward · · Score: 0

      Thus ensuring only "trusted" Operating Systems are ever installed and used on those computers. Your Disto can't afford to pay the cost of getting a digital signature, FY, no install for you. Roll your own distro, FY.

    36. Re:Whatever happened to... by rahvin112 · · Score: 2

      UEFI/EFI is coming to an ARM platform near you. It's needed for ARM to support server type capabilities and IIRC ARM plans to implement it across all future products to make it possible for their platform to expand into the server market.

      UEFI is here to stay. Personally I'd prefer coreboot but no one supports coreboot and the manufactures don't like it because they can't brand it as easily as UEFI can be.

    37. Re:Whatever happened to... by sjames · · Score: 2

      So why not throw the excess plumbing away and just have the BIOS call the secure boot module?

      EFI isn't needed for that, it just happens to be where it was implemented.

    38. Re:Whatever happened to... by sjames · · Score: 1

      That would be best, yes.

    39. Re: Whatever happened to... by jittles · · Score: 1

      As a security professional, I am a big fan of the concept of secure boot - not necessarily current implementations. The purpose of secure boot is to give me a known secure state of the system. I want that you can't drop some shit somewhere that will run underneath my ring 0 because it gets loaded first. If the boot process can ensure that my kernel gets loaded and handed control of the system, then I can be responsible from that point on and use RBAC or SELinux or OpenBSD secure levels or whatever to stay in control. But if some shit pre-empts me and puts itself between my kernel and the hardware, nothing I do matters.

      I much prefer Coreboot over UEFI for the same reason - control.

      And what exact protection does Coreboot provide that UEFI Secure Boot does not provide in this regard? If Secure Boot is properly implemented then there is no way to execute unsigned code unless someone physically flashes the chip with compromised firmware. But you could do the exact same thing with Coreboot, too. So is the advantage of Coreboot that you only trust code that you compile yourself? Because even with Coreboot you're using someone else's binaries at some point. Very few silicon vendors provide you with all the code that you need to perform platform initialization. With Intel, the best you can do is use their FSP binaries. And even if you have 100% access to all of the code, whose compiler are you going to use? Do you trust them? Because the compiler can also inject code that could compromise your system at build time.

      I would honestly love to hear your thoughts. But I don't think that having more control necessarily buys you anything. If there is a security issue with the code, there is obviously the advantage of being able to test and deploy a fix much faster than any manufacturer would ever be able to provide. I have been contemplating ways to improve the process of pushing patches down to the end user but it is a very risky proposition. If there is a bug in the silicon vendor's code you're still at their mercy for a fix, too.

      And sure - Coreboot doesn't have management mode and runtime services. That has its advantages but you'll find that even ARM is moving toward providing something similar to SMM in their reference code. Of course, ARM has the advantage of learning from Intel and AMD's mistakes and is enforcing virtualization / IOMMU on its management mode.

      There is definitely a lot of room for improvement in the firmware arena. I personally believe that the industry is going to move toward a more open firmware environment. However, I think that MOST end users and MOST enterprises will prefer to pay for commercially supported firmware. I also believe that something more sophisticated than a TPM is really necessary to protect against physical presence attackers.

    40. Re:Whatever happened to... by jittles · · Score: 1

      The correct way to protect the BIOS is a jumper that has to be set to enable writing/erasing the flash. End of story.

      The old BIOS already managed to init the CPU, init the memory controller, init the memory, and provide enough setup of PCI devices to find the boot loader or jump to PXE.

      I have actually written boot firmware. Most of those complex things beyond what I mentioned above are complex because they don't belong in the boot firmware at all.

      Yep. That's exactly what Google, Facebook, Amazon, and everyone else wants in their data centers. They want to unrack hundreds of thousands of servers to fix a critical security issue. That's exactly what every single end user wants to do, as well. Most end users aren't even sophisticated enough to know that firmware exists, let alone sophisticated enough to know that it needs to be updated. Good luck getting them to set a jumper.

      I think the problem that the UEFI forum has is that so many businesses have a stake in the game and need competing functionality. If you're writing firmware for a single piece of hardware then you don't really need a lot of code. But if you want a platform that is flexible and able to deploy in basically any configuration the end user might possible desire, then you end up with something monolithic like EDK-II. However, the advantage to using something like EDK-II is that there is very little platform specific code outside of the PI phase of boot. So security issues can be fixed and deployed much faster than with traditional BIOS where code reuse was much more difficult. and typically vendor specific.

    41. Re:Whatever happened to... by sjames · · Score: 1

      If the BIOS contains any code that creates a security problem for a server, you've already screwed up. By the time the OS comes up, the BIOS should be a distant memory. If you need to upgrade it to support new hardware, you've already opened it up to change the hardware. If the user isn't sophisticated enough to know firmware exists, how would they ever come to the conclusion they need to update it?

      You would be surprised how modular BIOS can actually be without a complex API. It starts with the CPU specific code, moves on to the platform specific code, then the more generic code. All without a filesystem, memory allocator, or stored variables beyond a few bytes in CMOS.

    42. Re:Whatever happened to... by Anonymous Coward · · Score: 0

      In mind comes storage limits, loadable keys and the module size. Not that I know anything about the issues.

    43. Re:Whatever happened to... by jittles · · Score: 1

      If the BIOS contains any code that creates a security problem for a server, you've already screwed up.

      How can the firmware not have the potential to create a security problem for the OS? The firmware hands off execution to the OS. Even if the firmware does not persist after boot it can still maliciously modify the OS. Let's suppose that the firmware needs to access the USB controller so that a keyboard can be used during boot. If there's a security hole in the USB driver then the system can be owned long before the OS ever loads. The world you are describing, where the firmware is not part of the foundation of trust, is a complete fantasy. Even if you can guarantee that the firmware has not been tampered with prior to executing it an attacker can exploit vulnerabilities to modify it or the underlying operating system during execution..

      By the time the OS comes up, the BIOS should be a distant memory.

      You are not the only person who feels that way. And certainly runtime services are the most dangerous parts of firmware - they enable an OS level attacker to take greater control of the hardware. Unfortunately, I do not think they are going to go away. ARM is in the process of making their management mode and runtime services more sophisticated. Thankfully the ARM people are requiring virtualization to be use to help improve security. I do not think runtime services will go away any time soon (at least in mainstream computing).

      If the user isn't sophisticated enough to know firmware exists, how would they ever come to the conclusion they need to update it?

      This is why the UEFI specification provides capsule updates. The idea is that the OS is able to push firmware updates through it's update channel. The cryptographic signature of the update is verified in management mode and then stored in memory. The OS then shutdowns and the CPU resets without the MOR bit set. The firmware now has complete control of the system. It validates the cryptographic signature again, at a time when no attacker can be present (barring a debug connection over JTAG or something similar). If the signature is valid, it writes the flash. The user has no idea that the firmware was updated. They still have no idea that the firmware exists. But the software is fixed. Microsoft is pushing very hard in that direction. Apple, having control over the OS and the firmware, already implements this. Linux also has a tool for pushing firmware capsule updates.

      You would be surprised how modular BIOS can actually be without a complex API. It starts with the CPU specific code, moves on to the platform specific code, then the more generic code. All without a filesystem, memory allocator, or stored variables beyond a few bytes in CMOS.

      Any properly engineered code is modular and a complex API is never required. However, historical bios had no standard. And vendor lock-in was a real concern. So how do you prevent lock-in? You make a standard. The standard is complex in this case because of the business needs of the various members of the UEFI forum. I think that improvements definitely need to be made to the specification to enhance security. However, going back to "good ol' bios" is not the best way to do it. I think we would be better off increasing the transparency of the firmware. I would like to see a solution that allows the average computer user to not have to worry about firmware and allow power users like yourself to run Coreboot or whatever you want. Allow your typical corporation to run standard firmware or to roll their own firmware solution without worrying about cryptographic keys being fused into the chipset on their motherboard. But there needs to be some set of standard(s) that everyone is held to or we'll just end up going back to the wild wild west.

    44. Re:Whatever happened to... by sjames · · Score: 1

      If the firmware isn't writable, it won't get corrupted by an attacker in the first place. Making it updatable without physical intervention actually PROVIDES the attack vector that you then have to create security updates to protect.

      As for a hacked USB device, it is widely believed that physical access == game over in any event.

      The idea of the OS update channel being able to apply updates to the firmware is a big screaming NO! It's bad enough that the OS is changing out from under the user.

      As for vendor lock-in, it is still being accomplished through NDA's, undocumented but necessary information and blobs. EFI did nothing to fix that.

    45. Re:Whatever happened to... by AmiMoJo · · Score: 1

      Well, for example, you probably need some way to init the GPU to the point where it can provide a basic display for the OS to boot with, or display a boot menu and error messages. So you need a way to configure arbitrary GPUs, and ideally you don't want it to be like the old BIOS stuff that was just x86 code in a ROM chip. So actually you do need EFI.

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
    46. Re:Whatever happened to... by jittles · · Score: 1

      If the firmware isn't writable, it won't get corrupted by an attacker in the first place. Making it updatable without physical intervention actually PROVIDES the attack vector that you then have to create security updates to protect.

      As for a hacked USB device, it is widely believed that physical access == game over in any event.

      The firmware does NOT need to be overwritten to be attacked and exploited, even if it does not persist into runtime. It just needs an exploitable defect and someone/thing with an opportunity to exploit it. Runtime services extends the ability to exploit a firmware defect into the OS.

      And I do not need physical presence to own you with a compromised USB or PciE device. I only need to sit somewhere in your supply channel. I could be a plant at the keyboard factory. I could own the warehouse that stores all the keyboard while they're sitting on the dock waiting to ship. I could be a Customs agent inspecting the hardware before it enters or leaves the country. Any firmware can potentially be compromised in this manner. Making it impossible for an average user to fix the problem does not improve computer security.

      The idea of the OS update channel being able to apply updates to the firmware is a big screaming NO! It's bad enough that the OS is changing out from under the user.

      I do not like forced updates. The way that Microsoft pushes updates in Windows 8 and 10 should be illegal. But do you own a Mac? Do you own an iPhone? An android device? Those all get firmware updates pushed down to the hardware during OS updates also. Until people start writing perfect code updating needs to be possible. I think you'd be better off trying to help solve the problem of safe and secure updates than bemoaning the fact that you don't like the current state of firmware updates. It's not likely to change. The number of computing devices in the world has grown exponentially since you touched your first computer. Everything has firmware in it these days, from your car, to your refrigerator, and even many children's toys.

      As for vendor lock-in, it is still being accomplished through NDA's, undocumented but necessary information and blobs. EFI did nothing to fix that.

      That is not true. I can write an EFI driver / module and use it without modification on any EFI compatible firmware - whether it is AMI, Insyde, Phoenix, TianoCore, or any other EFI firmware. In fact, this makes it so much easier to extend capabilities to new platforms that SUSE actually submitted code to U-Boot to enable U-Boot to load and use EFI drivers and applications. SUSE is working on completing the Self Certification Tests (SCT) provided by the UEFI forum for its ARM platforms that are booted with U-Boot. The only thing preventing them from completing the SCT is the fact that the current standard does not define a way to "opt out" of runtime services. This has greatly reduced the complexity that SUSE faces when bringing up a new board. This is now the default configuration for U-Boot. You have to specifically disable EFI support.

    47. Re: Whatever happened to... by Tom · · Score: 1

      So is the advantage of Coreboot that you only trust code that you compile yourself?

      Yes. As I wrote, it's about control.

      And even if you have 100% access to all of the code, whose compiler are you going to use? Do you trust them? Because the compiler can also inject code that could compromise your system at build time.

      I'm well aware of that. Some 15 years ago I started a small security-focussed Linux distro (Nexus Linux was the name if I recall correctly) that tried to bootstrap everything from trusted sources. We never came to a first release, because it was essentially three people and the task is massive exactly for the reasons you outline. But the idea is there, with enough resources it is doable, if there were some support to pay one or two people full-time, you could build a system entirely from scratch with only trusted sources.

      Back in the early 2000s, we ignored the hardware/firmware problem because there was simply nothing we could do about that. But with Coreboot, that door has opened. I've personally been out of the low-level stuff for too long, it's been over 10 years since I wrote the last kernel module, but I still like the idea of having a distribution that has its foundations reviewed, trusted and compiled entirely from scratch and trusted sources. Above that you can build a Debian or whatever, no need to reinvent package management. For many security-conscious enterprises, it might be a worthwhile thing to invest in.

      --
      Assorted stuff I do sometimes: Lemuria.org
    48. Re:Whatever happened to... by sjames · · Score: 1

      Those opportunities will be hard to come by if the BIOS is a distant memory by the time networking is up. The on-disk bootloader would be a much "better" target for the bad guy and offers some chance at persistence.

      A USB device could be a problem if you boot from it, if the BIOS is configured to boot from USB, but EFI and/or firmware updates won't change that. PCI devices could certainly be a problem, though less so now that chipsets have an IOMMU. If the option ROM contains an exploit, again neither EFI or the ability to update firmware will make it go away.

      I am aware of how many things have firmware in them. I write some of it. Ignoring the KISS principle is the problem. Ignoring it harder isn't the solution to that problem.

      Note that in many of those things, the case for updatability is better since the firmware is the only ware on the thing and it provides all of the functionality including the user interface. That is a bit contrast to something that provides (or should provide) no user functionality other than loading the OS and going away.

      As a side note, don't forget that BIOS provides int 20 functions left over from the original IBM PC. Beyond the boot sector, it gets ignored completely, for good reason. I suspect the past will repeat itself.

    49. Re:Whatever happened to... by sjames · · Score: 1

      I don't NEED EFI. Initing the video card has been happening since before the first PC.

      I will concede that some sort of byte code could be a useful thing (divorced from EFI). For example, some other firmware systems used to support a FORTH interpreter. I even experimentally added one to LinuxBIOS at one time, but I ran out of time to work on it.

    50. Re:Whatever happened to... by Anonymous Coward · · Score: 0

      That could equally well be solved by letting the OS deal with that and suggesting peripherals for architecture X start in a decently functionnal mode, letting the customer chose either the cheap crap that outputs garbage until it got its megabyte firmware flashed or the nice one that dumps a industry-wide well-known address as an ASCII debug.

    51. Re:Whatever happened to... by jittles · · Score: 1

      Those opportunities will be hard to come by if the BIOS is a distant memory by the time networking is up.

      That is absolutely false. If you can compromise the firmware then it does not matter what is loaded afterward, you can modify it as it is loaded or before it is loaded. Even if you boot with PXE or HTTPS the firmware still has to load the eventual image. You can have a persistent threat that does not require the flash part to be compromised as long as you have a mechanism available to launch your payload. And the fact that you think this is the epitome of the problem we are currently seeing. The people who write the firmware just cannot honestly conceive of the attacks surface that they are presenting. The only way you'd be able to prevent the kinds of attacks I am talking about is by not loading a single driver to communicate with untrusted hardware. And good luck ever booting a useful general purpose computer that never loads a drive controller or network controller.

      A USB device could be a problem if you boot from it,

      Again this is incorrect. A USB device could be a problem if you communicate with it. At all. Even if it is just to enumerate the available devices. The firmware could communicate with a USB device for many purposes that have nothing to do with booting the OS. Obviously the attack surface presented by enumerating the devices is not as great as the surface presented when trying to use the device but software bugs can exist anywhere and even a simple typo could open you up to attack.

      Believe me, I am not trying to argue that there is no way to improve the situation. One of the nice things about Coreboot is that it does as little as absolutely necessary to initialize the system before passing control onto the OS. As you say, KISS reduces the opportunity for attackers by reducing the number of ways they can attack you. But there is no magic wand you can wave at security and that includes the wand of using ROM to load firmware.

      if the BIOS is configured to boot from USB, but EFI and/or firmware updates won't change that. PCI devices could certainly be a problem,

      And where does the USB controller sit? Inside the PCH on the PCI bus.

      though less so now that chipsets have an IOMMU. If the option ROM contains an exploit, again neither EFI or the ability to update firmware will make it go away.

      There have been attacks on IOMMU since at least 2011. And how do you mitigate this VT-D bypass? Through a firmware update. And you'd be naive to think that this is the only exploit possible against IOMMU.

      I am aware of how many things have firmware in them. I write some of it. Ignoring the KISS principle is the problem. Ignoring it harder isn't the solution to that problem.

      And what are you trying to keep more simple here? Because you're making it basically impossible for probably 95% of the population to update their firmware. By all means, strip out the cruft out of your firmware. Reduce your attack surface anywhere possible. But don't throw the baby out with the bath water and leave most of the world vulnerable by removing their ability to patch their firmware.

      Maybe you should look at what Google has done with the Chromebook. They use the silicon vendor's hardware protection of the flash part. They have their Titan device that is able to detect modified flash. They require a physical presence check when tampering with the machine in a way that might compromise the integrity of the device. You have to hit the power button five times in a specific time interval. Assuming that they've implemented their hardware and software properly then you'll find that

    52. Re:Whatever happened to... by sjames · · Score: 1

      That is absolutely false. If you can compromise the firmware then it does not matter what is loaded afterward, you can modify it as it is loaded or before it is loaded.

      I think you missed my point. The BIOS is out of the picture by the time the network is up. It is also read only. So that's a really big IF. You'll need to be physically present to set that jumper if you want to implant an APT into the firmware..

      Note that IOMMU and VT-d are not the same thing. VT-d is a way to give a real PCI device over to a VM.IOMMU includes preventing PCI cards from overflowing a memory/address space assignment at the hardware level. Likewise, the USB controller itself will enforce buffer limits. Since USB data transfer is host driven, the device doesn't have much opportunity to make trouble.

      Unless you implement a very simple PHY and depend on polling and bit banging to implement soft USB, that's not going to be a problem. (And if you DO implement that, you already have a problem or five).

      Note with all of this, it *IS* possible to update the firmware if you're physically present to set the jumper (or do the chromebook secret handshake as you pointed out). But again, if the firmware is read-only, you won't be installing an APT there.

      But in all of those scenarios, if it can work against a PC with an old BIOS, it will also work against a PC with EFI. However, since EFI doesn't play nice with read-only flash, you get a bonus that the evil USB or PCI device can implant an APT in the EFI such that removing the offending device and re-installing the OS won't help. You'd need tools that most repair shops and IT departments don't have.

      If you disable CSM then...

      Yes. Likewise, for similar reasons, I fully expect all that API in UEFI to be considered avoid at all cost in the future.

    53. Re: Whatever happened to... by sjames · · Score: 1

      And what exact protection does Coreboot provide that UEFI Secure Boot does not provide in this regard?

      If I may interject, the concept of secure boot only works as a security measure if the owner of the hardware is the sole owner of the key trusted to sign the bootloader and the OS. My machine, *I* sign the code I trust. MS's opinion doesn't matter. Intel's opinion doesn't matter.

    54. Re:Whatever happened to... by thegarbz · · Score: 1

      The old BIOS already managed to init the CPU, init the memory controller, init the memory, and provide enough setup of PCI devices to find the boot loader or jump to PXE.

      Yes and it did so just fine until those very processes became so complex they the didn't fit in the woefully inadequate structure BIOSes had to work with.

      Computers have grown more complex. Complexity breeds complexity.

    55. Re:Whatever happened to... by jittles · · Score: 1

      I think you missed my point. The BIOS is out of the picture by the time the network is up. It is also read only. So that's a really big IF. You'll need to be physically present to set that jumper if you want to implant an APT into the firmware..

      You’ve missed the point. Whether or not your firmware is read only, if I can compromise the firmware while it is running then I own the machine. Whether it persists or not. By the time it hands off execution to your OS the entire system is untrustworthy. End of story. It doesn’t matter if the network stack is not available until next week, I owned the machine and still own it when next week rolls around.

      Note that IOMMU and VT-d are not the same thing. VT-d is a way to give a real PCI device over to a VM.IOMMU includes preventing PCI cards from overflowing a memory/address space assignment at the hardware level.

      And how does IOMMU work? If you’re on an Intel box it uses... VT-d. If it’s on an AMD box, AMD-V. If there is an exploit in VT-d there is a potential exploit in IOMMU because it works through VT-d.

      Likewise, the USB controller itself will enforce buffer limits. Since USB data transfer is host driven, the device doesn't have much opportunity to make trouble.

      Unless you implement a very simple PHY and depend on polling and bit banging to implement soft USB, that's not going to be a problem. (And if you DO implement that, you already have a problem or five).

      You’re still missing the point. Any time the attacker supplies data, there is a potential for exploit. And how do exploits come about? From software bugs. How do you fix a bug? With a patch. And how does 95% of the world patch their firmware if they have to physically open the device? They don’t. Plain and simple. What you are proposing as a valid solution to firmware exploits is not feasible.

      Note with all of this, it *IS* possible to update the firmware if you're physically present to set the jumper (or do the chromebook secret handshake as you pointed out).

      How many servers does Google own? How many man hours will it take Google to physically unrack and jumper every single server they own? Or even do a secret handshake with each device.

      But again, if the firmware is read-only, you won't be installing an APT there.

      Do you understand that this issue is 100% mitigated by enabling Secure Boot? They can add extra drivers and it won’t execute them if not properly signed. Everyone should be using Secure Boot. Even if you want to custom build your own Gentoo platform, you should sign it and add your public key to the DB on your platform. And if someone creates a malicious device with a valid signature? The signing key gets revoked and the driver never gets executed.

      But in all of those scenarios, if it can work against a PC with an old BIOS, it will also work against a PC with EFI.

      Sure, there is always the potential for the exact same defect to exist in both old BIOS and EFI firmware. The code could be almost identical, copy/pasted from the one to the other. But the difference is the fact that there is at least a chance that the user will upgrade their firmware if they do not have to disassemble the hardware first.

      However, since EFI doesn't play nice with read-only flash, you get a bonus that the evil USB or PCI device can implant an APT in the EFI such that removing the offending device and re-installing the OS won't help. You'd need tools that most repair shops and IT departments don't have.

      Sure, but if the evil device is still attached then it does not matter whether it can implant an exploit if it is able to repeatedly exploit. However, you should be able to update the firmware even if a malicious PCI device is present as long as secure boot is enabled. But again, if secure boot i

    56. Re: Whatever happened to... by jittles · · Score: 1

      And what exact protection does Coreboot provide that UEFI Secure Boot does not provide in this regard?

      If I may interject, the concept of secure boot only works as a security measure if the owner of the hardware is the sole owner of the key trusted to sign the bootloader and the OS. My machine, *I* sign the code I trust. MS's opinion doesn't matter. Intel's opinion doesn't matter.

      You are living in a different world than most people. 99% of the people in the world do not want what you want. But you’re welcome to modify your firmware to revoke Microsoft’s root of trust and inject your own. You’re already able to inject your own but I don’t think you’ll be able to get a UEFI device without Microsoft’s key unless you modify the binary or pay to have custom firmware. I am 100% certain that there are data centers who use only their own key, but they’re buying hundreds of thousands of identical servers. There are completely open devices out there that you can use to run Coreboot with only your own code. Some brands offer Coreboot versions of firmware. If you do some searching on the Internet I am sure you can find exactly what you are looking for.

    57. Re:Whatever happened to... by sjames · · Score: 1

      If the firmware can be changed, that includes the trust DB or the code that checks the signatures.

      If someone prefers convenience over security, they can set the jumper when they set up the machine. If they want a middle way, they can replace the jumper with a switch on the front panel.

      You're right that most people don't care. They just turn secure boot off too since that may also be inconvenient later.

      Essentially, you are advocating to open a REMOTE vulnerability just in case you want to apply a patch to close a vulnerability that requires physical presence to exploit. In reality, there are a lot more people halfway across the world who might like to take advantage of a remote vulnerability from the safety of their basement then there are people willing to actually enter my server room (where they might actually face arrest) to carry out an exploit.

      There is also a matter of scale and target value. Nobody is going to fly halfway across the world to attack my server. But plenty of bad people might put significant effort into a hack where they could compromise thousands of servers in a single night with a bad update.

    58. Re:Whatever happened to... by sjames · · Score: 1

      So what magic is it that EFI is somehow able to fit, but a BIOS supporting the old ABI just can't manage?

      BIOS has been going into flat-32 mode for some time. Are you saying a 4GB address space just isn't big enough?

    59. Re:Whatever happened to... by jittles · · Score: 1

      If the firmware can be changed, that includes the trust DB or the code that checks the signatures.

      If firmware signatures are required then no, you cannot change the trust DB, at least not for the root of trust. And you can use the TPM and authenticated variables to protect any key that has been added by the end user. If that gets corrupted, you just drop the data and force the user to add the key again. That requires physical presence.

      If someone prefers convenience over security, they can set the jumper when they set up the machine. If they want a middle way, they can replace the jumper with a switch on the front panel.

      Which will result in everyone except yourself a a handful of other people leaving the jumper set. And since you seem to be against using anything like cryptographic signatures to validate the firmware that leaves us worse off than we are not for everyone except you and a few other people.

      You're right that most people don't care. They just turn secure boot off too since that may also be inconvenient later.

      For people who don’t know anything about firmware and just don’t care they don’t know that secure boot could be an inconvenience. So they leave it on if they bought a pre-manufactured machine and likely leave it off if they built the system from components.

      Essentially, you are advocating to open a REMOTE vulnerability just in case you want to apply a patch to close a vulnerability that requires physical presence to exploit.

      Well hold on now. You’re moving the goal posts on this conversation. SInce when did your legacy BIOS not have runtime services? If it has runtime services it can be just as easily exploited as any UEFI firmware. And now you’ll say “Oh but the person will detect the virus and eventually wipe their drive and the virus will go away.” But the sad reality is that the person will still continue to download that “Hello Kitty” mouse cursor pack and they will end up with the exact same virus again. Have you ever had to help a friend or family member with such problems? They do not ever go away unless you move them onto an OS that has a lot lower risk (Linux or OSX). They engage in the exact same behavior as before and get the virus again and again no matter how many times you fix it for them. It does not matter whether their firmware was writeable. They will continue to get infected. And since they aren’t going to patch their ME or PSP (again because their firmware is NOT writeable without a jumper that will never get set), we find that they actually have remotely exploitable firmware vulnerabilities that do not even require the target system to be powered on - just connected to the same LAN as another machine that is infected.

      Unless you can wave your magic wand and make ME, PSP, and writeable flash disappear you NEED to have updateable firmware. I’m not sure how I can make this any more clear to you. The hardware has the capability to protect the flash. The flash should NOT be writeable during the OS execution. It should only be writeable when someone enables a setting that can only be configured with physical presence while the firmware is running only trusted code. A properly configured machine cannot have this exploit written to flash. And even if they use a dediprog to physically write the data to the flashchip, a properly configured machine will ignore it. Will your legacy bios refuse to execute code that someone physically flashes onto the chip with a programmer?

      In reality, there are a lot more people halfway across the world who might like to take advantage of a remote vulnerability from the safety of their basement then there are people willing to actually enter my server room (where they might actually face arrest) to carry out an exploit.

      Nobody is arguing that. But the reality of the sit

    60. Re: Whatever happened to... by sjames · · Score: 1

      A funny thing with secure boot in UEFI. Why can't the bad guy just turn it off or replace your key with his own and then sign a new corrupted bootloader?

      You can check what key is installed once the system boots, but if you're unknowingly running the bad guy's patched kernel, you can't trust the results of the check.

      It's turtles all the way down.

    61. Re:Whatever happened to... by sjames · · Score: 1

      The goalpost didn't even quiver. If the BIOS is read only in hardware, nobody's going to implant an APT in it by any means other than physically setting the write enable jumper PERIOD. Exploiting the SMM or even the ME can't change that.

      Keep in mind, we're talking about the value add for writable firmware here, so the face that the OS might be corrupted after being booted (for example, through an obscure TCP stack vuln) is irrelevant since that can happen no matter what booted it.

      An ME vuln CAN disable checking firmware signatures. That has actually been demonstrated. But if writing is disabled in hardware, no remote attack can change that.

      TL;DR my point is that we would be better off tossing out ME, EFI, SMM and all the other complexities and just use a simple old school firmware that you have to be physically present to make writable. None of that stuff adds to YOUR security, but it can certainly provide aid and comfort to your enemies (known and unknown).

      I am well aware that that isn't the direction industry is choosing. Whaty does that sau about the industry and your relationship to it?

    62. Re:Whatever happened to... by thegarbz · · Score: 1

      BIOS has been a mixture of incredibly and increasingly uglier hacks as it's grown beyond it's initial scope and size while maintaining backwards compatibility which made absolutely no sense on modern hardware.

      You think EFI is bad? More power to you. I think the hackjobs that were BIOSes are worse. FYI the code required to initiate HyperTransport in the latest AGESA firmware from AMD is larger than the entire BIOS was pre-EFI, and that's just a small portion of getting a small part of a modern system to boot.

    63. Re:Whatever happened to... by sjames · · Score: 1

      I have actually disassembled BIOS before. I'm not against a massive clean-up of some of the nasty proprietary code. For example, CoreBoot + SeaBIOS is good.

  10. Same old mistakes, made again and again and again by gweihir · · Score: 2

    I am really tired of everything new being broken. We do know how to do this better. Why are these severe mistakes still being made?

    --
    Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
  11. The state of IT is a tragedy by Anonymous Coward · · Score: 5, Insightful

    Anyone with a working brain can see that non-removable persistent storage on the mainboard, that can be written from inside a running OS and only be inspected under the control of the software in that storage, is an extraordinarily stupid mistake. Then there are a variety of "management" systems (SMM, IME, ...) which also evade inspection and have full access to everything. The most trustworthy computers these days are small embedded processors (but not phones!). Desktop systems and laptops can practically not be secured. If there is a possibility of a hack, there is no reliable way to restore the system to a safe state.

    1. Re: The state of IT is a tragedy by Anonymous Coward · · Score: 0

      Interesting read. The release notes would be much clearer. I am looking forward to reading them. First thing I noticed (though it wasnâ(TM)t called out specifically) was the use of page faults to attack multiple parts of memory at once and how that is a particularly effective attack in a parallel or distributed computing environment. Second, I see that it is packaged in fast mode with all range checking etc off and in a single executable with lazy loading dlls built right in. Very impressed! Like I said, Iâ(TM)m looking forward to slightly more standard FAQs on these things once the devs get done with the analysis but I got the gist.

    2. Re:The state of IT is a tragedy by Anonymous Coward · · Score: 0

      Don't get me started. UEFI is an epic fuck up.

      The BIOS needed updating, badly.

      Intel went away and thought... what it really needs is an operating system sized BIOS.

      The ONE area where simplicity was badly needed was the BIOS replacement.

      But no... Intel decided it make it insanely complex because... the real desire was control. The ability to seal the hardware in a bubble of software that's opaque and totally controlled by the tech companies - and by extension, the authorities.

      Just how many operating system kernels are there now sitting between Linux (or BSD, or windows) and the actual hardware? And those are the ones you KNOW about - and not even counting the ones that sit outside your hardware and police it.

      Fuck you Intel. Just fuck you.

    3. Re:The state of IT is a tragedy by AmiMoJo · · Score: 1

      Most microcomputers have had some kind of non-volatile storage since the dawn of time. Some of the 8 bit machines didn't, but even early PCs had a real-time clock and battery backed boot settings RAM.

      Of course back then there was no access control at all, every app could access the hardware directly.

      Think about how long UEFI has been around and how long it has taken to find an exploit. It's really not that badly designed at all, at least not from a security perspective. Note that enabling Secure Boot mitigates the attack entirely.

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

      You mean how long it has taken to find an exploit being used in the wild. It's no surprise it took that long, considering how well it is hidden, which is the point. Early PCs had write protection jumpers, and the BIOS was not designed to be written to in normal operation or even from within the BIOS. The BIOS flash memory was a replacement for EPROMs, which you had to take out of the board to erase and reprogram them. Write protecting that storage was feasible because it functionally replaced ROM. Boot settings could be erased to factory defaults with another jumper or by removing the backup battery for a moment. If you erased the BIOS configuration that way, and the BIOS flash write protection jumper was in place, you could be reasonably sure that you had a clean system ready for a fresh OS install. There is no way to reset a modern PC to a known-good state. IMHO computers should not have any non-removable writable storage, except for a few simple fuse-style configuration bits. The minimal initialization should be in ROM and load the firmware from removable media. Alternatively the on-board memory should have a separate hardware interface which makes the complete firmware memory accessible to an external system. The goal is to provide a reliable way by which a user can ensure a clean state of the system after a possible infection.

    5. Re:The state of IT is a tragedy by drinkypoo · · Score: 1

      but even early PCs had a real-time clock and battery backed boot settings RAM.

      Not my early PC. My first PC was an IBM 5150 (aka "PC-1") and I had to have a RTC on an expansion card because it didn't have one onboard. That expansion card also had 384kB of RAM. Installed in an XT, it would get you up to 1MB. In a PC, it would get you to 448kB. And you had to run a special command to get/set the RTC, naturally.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    6. Re:The state of IT is a tragedy by AmiMoJo · · Score: 1

      Mine was an Amstrad PC1512. The RTC was built in, but needed 4x AA batteries for some reason. It was a weird but generally decent machine.

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
    7. Re:The state of IT is a tragedy by jittles · · Score: 1

      Most microcomputers have had some kind of non-volatile storage since the dawn of time. Some of the 8 bit machines didn't, but even early PCs had a real-time clock and battery backed boot settings RAM.

      Of course back then there was no access control at all, every app could access the hardware directly.

      Think about how long UEFI has been around and how long it has taken to find an exploit. It's really not that badly designed at all, at least not from a security perspective. Note that enabling Secure Boot mitigates the attack entirely.

      It has taken this long because there were so many easier targets, not because the implementation by any vendor was especially well implemented from a security standpoint. Firmware has plenty of security problems and the industry is working to make it better. The UEFI forum has been considering security for some time, and I think that the specification covers *most* of the problems that any firmware can be susceptible to. However, the physical root of trust does not provide any sort of protection against a physically present attacker. Silicon vendors have implemented technology to protect against them - such as Intel Boot Guard, but I am not a fan of the implementation. It depends on a signing key being fused into the PCH during the manufacturing state of the system. This ties your hardware to one key forever. A key that can be compromised and that would be irrevocable. Google and Microsoft have designed hardware to detect modification of the SPI flash but I am not sure that they adequately provide protection, either. It is very difficult to protect against a physically present and sophisticated attacker.

  12. Re:Same old mistakes, made again and again and aga by Anonymous Coward · · Score: 0

    Why aren't manufacturers being sued for criminal negligence?

  13. Re:Same old mistakes, made again and again and aga by 110010001000 · · Score: 3, Funny

    Don't worry. AI and autonomous driving and quantum computing are right around the corner. That will fix all these issues.

  14. Re:Same old mistakes, made again and again and aga by cstacy · · Score: 1

    Don't worry. AI and autonomous driving and quantum computing are right around the corner. That will fix all these issues.

    No, because then the malware writers will 3D print their virus!

  15. Re:Same old mistakes, made again and again and aga by DCFusor · · Score: 1

    I don't think it's a matter of not knowing how...I think other forces are at play in making some of these mistakes. Just IMO, but I've done my time in this game. And it's not so simple a function as to be a short drop-down list unless you just want to put an entry on it like "human nature" or "I've got kids to feed" or "it looks good for the next quarter" - which explain little other than that humans do dumb technical things for dumb human motivations that prioritize other than getting it really right technically.

    --
    Why guess when you can know? Measure!
  16. Re:Same old mistakes, made again and again and aga by 3seas · · Score: 1

    Thank you thank you thank you 110010001000 as I certainly realize you are being facetious. Good to know I'm not the only one recognizing the generally ignored via Tunnel vision AI experts of the dangers of AI tech

  17. Re:Same old mistakes, made again and again and aga by sjames · · Score: 1, Troll

    Because NEW is seen as a virtue in itself. Rather than just make a needed improvement to old, we throw away the years of debugging and testing and jump into making something NEW. Often the argument is that the NEW can be much simpler. Alas, then a zillion corner cases pop up that explain well why OLD was as complex as it was. But now we have NEW, so OLD must go!

    So here we are with NEW and decades less debugging and testing behind it, no discernible benefit over OLD, and bugs are coming out of the wood work.

    Don't get me wrong, new has it's place, just not in fundamental code that everything else depends on.

  18. Re:Same old mistakes, made again and again and aga by 3seas · · Score: 1

    From my POV and experience, the tech industry is slowly crashing as the fails are increasing in numbers. And like cooking a frog, turning up teh heat slowley, so the tech industry is like the frog cooking itself.

  19. Re:Same old mistakes, made again and again and aga by Aighearach · · Score: 1

    It is true. Demand legacy software support. Go stable, go old.

  20. Re:Same old mistakes, made again and again and aga by Aighearach · · Score: 1

    The frog stuff is a weird myth, not a real thing.

  21. Re:Same old mistakes, made again and again and aga by Anonymous Coward · · Score: 0

    We are in deep sht because of greedy giant companies. M$ and intel designed this UEFI to be a pain in case u wanted to install Linux. Same with systemd, thanks to Red Hat and its minion who built systemd.

  22. Never Digital Rights Management. by Anonymous Coward · · Score: 0

    Since there is no such thing is the Linux kernel. And there never will be.

    Also, it’s Digital RESTRICTION Management anyway. ;)

  23. UEFI and persistent code by Anonymous Coward · · Score: 3, Insightful

    So UEFI allows persistent code to exist in it from a 3rd party for example these laptop security/tracking apps? Who didn't think this would eventually be abused by malware or some 3 letter agency?

    What's even better than the malware back in the day that would attempt to modify known BIOS code, or maybe brick a BIOS it didn't know? A known documented API into UEFI that allows for "sanctioned" persistent code! yay!

    UEFI and IME sounds like a 3 letter agencies wet dream.

    1. Re:UEFI and persistent code by Anonymous Coward · · Score: 1

      It was DESIGNED INTENTIONALLY for the purpose of hosting persistent "malware", where the definition of "malware" is "any code performing a function that is not desired by the owner of the hardware on which that code runs" and infecting the Operating System with this "malware" so that it carries out functions contrary to the wishes of the owner of the hardware.

    2. Re:UEFI and persistent code by jittles · · Score: 1

      So UEFI allows persistent code to exist in it from a 3rd party for example these laptop security/tracking apps? Who didn't think this would eventually be abused by malware or some 3 letter agency?

      What's even better than the malware back in the day that would attempt to modify known BIOS code, or maybe brick a BIOS it didn't know? A known documented API into UEFI that allows for "sanctioned" persistent code! yay!

      UEFI and IME sounds like a 3 letter agencies wet dream.

      No, it does not allow persistent code to exist any more so than any other firmware does. In fact, if you implement the UEFI specification and enable secure boot, this attack is impossible. Even if someone is able to add the payload to your flash file system, the firmware will detect the unsigned code and not load the module. The only way to prevent this kind of attack is to use a ROM. The problem with using a ROM is that any security issue that is found is entirely impossible to mitigate without replacing the ROM.

    3. Re:UEFI and persistent code by Anonymous Coward · · Score: 0

      I think you're thinking way high level. You do know all this comes way before any kind of boot loader is involved right? were talking about the what would have been the equivalent to the DIP packaged BIOS ROM on a PC of 15 years ago. Those these days the fucking "BIOS" is an OS all in itself.

      Ever wonder why when you turn on a PC of the last decade and a half it doesn't just immediately come on, but takes 15 seconds or so? its booting the kernel of the mystery OS embedded in UEFI and IME before it even thinks of loading whatever boot loader you have on disk.

      Gotta miss the old school days of 256K DIP packaged EEPROM BIOS, least there wasn't much space to do so much damage to your privacy.

      Ever flash the "BIOS" on a modern PC and even for how fast they are realize it takes like 5 minutes, hmm, how much code is it flashing? old school 256K EEPROM days that took a few seconds.

  24. Re:Same old mistakes, made again and again and aga by ctilsie242 · · Score: 3, Interesting

    Money. To a lot of companies, the top brass feels that security gives zero return to them, so they skimp as much as possible on it. In fact, the faster they can rush a product out the door, no matter how many odious show-stopping bugs, the better.

    I wish we had something like Underwriter's Laboratories, except for computer product security, and security in the correct ways, as most companies only focus on security against the intended user, so a broken device can't be reflashed with custom firmware and made useful again. Or perhaps, take that one step further and go with a Sold Secure like system, where products are white-box tested, black box tested, source code is audited, chip supplies are audited, and so on. Of course, the downside here is regulatory capture, but if this is a multinational organization with people who are not beholden to one country, this could be an acceptable solution.

    Until this, or some regulatory system is in place, these compromises will only happen more often, as one attack based on UEFI allows others to happen, and we have only seen the start persistant threats. Things like ransomware that quietly encrypts files via a transparant driver, so even backups have the files encrypted, then a certain date elapses, and the decryption keys are chucked, all drives are ATA locked and the machine puts up a message demanding whatever currency is in fashion (Bitcoins, e-Gold, etc.)

  25. Re:Same old mistakes, made again and again and aga by sfcat · · Score: 1

    Thank you thank you thank you 110010001000 as I certainly realize you are being facetious. Good to know I'm not the only one recognizing the generally ignored via Tunnel vision AI experts of the dangers of AI tech

    The dangers of AI tech are the same as the dangers of "trusting the computer". ML algorithms all have an error rate. That's part of the package. The problem is that humans don't seem to understand this. This is fixable just as people now understand that the DB might have been updated incorrectly and there might be a mistake that can be investigated.

    --
    "Those that start by burning books, will end by burning men."
  26. Wait wasn't UEFI supposed to protect us? by Anonymous Coward · · Score: 1

    Of course, silly me -- UEFI was never about protecting people's OSes from viruses, as originally claimed -- it was about enabling big vendors like Microsoft to be gatekeepers of what OSes we can install on *our* hardware; and adding lots of yummy complexity in which to hide backdoors for spooks.

    1. Re: Wait wasn't UEFI supposed to protect us? by Anonymous Coward · · Score: 0

      Many called this out in the beginning but were told they were just being immature and clinging to the past.

      Is there a website where one can cement ones feelings that is locked up after a time period, with points assigned years later for predictions that were correct and no way for those who were wrong to hide or change their previous post?

      Im tired of being right and having no way to rub other peoples faces in it.

  27. Re:Same old mistakes, made again and again and aga by BoRegardless · · Score: 1

    "... Because we need everything to be new & better & faster with "more connections" so we can keep collecting fees for the new exciting version xyz.12b23 and keep our income coming in ... "

    It is a crock. We don't need more than a few standard features to run business.

    Ever heard of the Rube Golberg OS, aka Windows?

  28. Hypervisor impact ? by Anonymous Coward · · Score: 0

    Assuming this is null in void on a UEFI equipped computer running a windows vm in a hypervisor ? Seems a bad a idea to run anything outside of a sandboxed VM now a days.

  29. Re:Same old mistakes, made again and again and aga by Anonymous Coward · · Score: 0

    Why? Listen to the Rolling Stones/Marianne Faithful "As tears go by" and then you'll know.

  30. Re:Same old mistakes, made again and again and aga by Anonymous Coward · · Score: 0

    Why do you believe there are any "mistakes" and the system is not working entirely as designed?

  31. Re:Same old mistakes, made again and again and aga by phantomfive · · Score: 2

    Because software teams only fix critical and important bugs. They have tons of bugs left in their bug tracker, and some of them happen to be security bugs.

    --
    "First they came for the slanderers and i said nothing."
  32. Re:Same old mistakes, made again and again and aga by Anonymous Coward · · Score: 0

    Why do you think they are negligent? Just because *YOU* do not like the design does not mean that the design is negligent, only that YOU do not agree with it. Thus the problem is entirely and completely YOUR NEGLIGENCE in failing to understand the intended operation.

    One man's fish is another man's poison.

  33. Re:Same old mistakes, made again and again and aga by Anonymous Coward · · Score: 0

    One man's fish is another man's poison.

    You misspelled "poisson".

  34. Secure Boot by Anonymous Coward · · Score: 0

    Secure Boot allegedly prevents infection from Lojax. Most OEM systems ship with Secure Boot active, so the vast majority of Windows UEFI machines are not vulnerable. Users generally don't know enough to disable Secure Boot on their own. The current attack vector is in the form of Windows malware. If you are using a Linux distro that does not have keys for Secure Boot, you still can't get it (yet) since the observed attack vendor will not function in your OS environment.

    There may be a Linux version of Lojax out there by now. The article does not discuss that possibility.

  35. Re:Same old mistakes, made again and again and aga by Anonymous Coward · · Score: 0

    $1.2 billion got approved for quantum computers in those budgets that Trump won't sign.....

    I doubt we'll ever see the back of "Entanglement teleportation across space and time" given how much money is invested to propagate that lie.

    One thing to have a bug, another to be invested in pretending the bug is a feature! Especially now IBM is in on the fraud.

  36. This is why machines should have a factory reset by davidwr · · Score: 1

    Granted, a factory reset would make things like Computrace impossible, but it will mean you can be confident you are back in a known good state.

    --
    Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
  37. Re:Same old mistakes, made again and again and aga by Anonymous Coward · · Score: 1

    I am really tired of everything new being broken. We do know how to do this better. Why are these severe mistakes still being made?

    They're not severe mistakes. They're severe INTENTIONAL mistakes.

  38. By enabling Secure Boot ... by benjymouse · · Score: 2

    By enabling Secure Boot, and making sure their UEFI firmware is up to date, end users can protect themselves against attack, Vachon said.

    This rootkit is *NOT* a bypass of secure boot. If UEFI Secure Boot is enabled, unsigned UEFI modules cannot be installed into the UEFI firmware configuration.

    We've seen BIOS rootkits before. This is just an UEFI version of the same concept, except UEFI Secure Boot does exactly what it is supposed to do: Prevent unauthorized updating of the firmware.

    --
    Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
  39. Re:Same old mistakes, made again and again and aga by Zocalo · · Score: 1

    It actually has a basis in fact - the "experiment" was conducted - but people tend to use the analogy in the context of the frog getting boiled. In fact, the frog will actually jump out of the water once it becomes too warm for the frog, so the correct usage would be to either describe the scenario and posit a "what you you do?" type scenario, or make the actual outcome clear with the implication that even a frog is smart enough to get out of the water.

    --
    UNIX? They're not even circumcised! Savages!
  40. Re:Same old mistakes, made again and again and aga by gweihir · · Score: 1

    Well, autonomous driving may be real and fix it. If I get run over, I do not have to deal with this crap anymore!

    --
    Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
  41. Complete video of talk by stefanb · · Score: 2

    is available, like most of the talks for 35c3, on media.ccc.de: https://media.ccc.de/v/35c3-95...

    1. Re:Complete video of talk by Anonymous Coward · · Score: 0

      THANK YOU for helping my eyes parse the logo on the front of the podium. It was driving me batty. I skimmed the original post too quickly and kept trying to see how that looked like "ESET"

  42. windows lock in is not what we need or apple store by Joe_Dragon · · Score: 1

    windows lock in is not what we need or apple storage lock in where you pay a lot more then other systems to have the storage locked to the MB.

  43. can i use it to boot slackware? by Anonymous Coward · · Score: 0

    if so, where can i find it on github...or can you point me to the nearest free walmart gift card site?

  44. Re:Same old mistakes, made again and again and aga by AmiMoJo · · Score: 2

    Actually things are much, much better than they used to be.

    This attack requires the user to first compromise the OS in order to attack the UEFI firmware, so they need multiple unpatched vulnerabilities. Realistically that means either tricking the user into running some malware or getting through the web browser, the web browser's sandbox, the OS sandbox, the OS user level protections, the OS kernel security protections and finally attacking the particular UEFI implementation being used.

    Compare to back in the 90s when everyone ran Internet Explorer as admin and code running in the browser itself could effortlessly install a rootkit. The filesystem was FAT32, it didn't even have access controls.

    These days exploits tend not to be nearly as serious because we have so many layers of defences. That's one reason attacks have changed in nature, focusing on things like the CPU itself or on stealing information rather than trying to take control of the system.

    --
    const int one = 65536; (Silvermoon, Texture.cs)
    SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
  45. Re:Same old mistakes, made again and again and aga by Anonymous Coward · · Score: 0

    Not mistakes - surveillance.

    The idiots amongst the national security management STILL don't get that there is no such thing as a backdoor for the good guys only.

  46. Re:Same old mistakes, made again and again and aga by Anonymous Coward · · Score: 0

    You're right. Someone may find it very helpful for UEFI to hold malware. Myself? Not so much.

  47. APK Hosts File Engine to the rescue (again) by Anonymous Coward · · Score: 0

    0.0.0.0 secao.org
    0.0.0.0 ikmtrust.com
    0.0.0.0 sysanalyticweb.com
    0.0.0.0 lxwo.org
    0.0.0.0 jflynci.com
    0.0.0.0 remotepx.net
    0.0.0.0 rdsnets.com
    0.0.0.0 rpcnetconnect.com
    0.0.0.0 webstp.com
    0.0.0.0 elaxo.org

    FROM https://www.welivesecurity.com...

    * Block those in your hosts file to NULLIFY this threat...

    APK

    P.S.=> For the best hosts file:

    APK Hosts File Engine 2.0++ 64-bit for Linux h t t p : / / a p k . i t - m a t e . c o . u k / A P K H o s t s F i l e E n g i n e F o r L i n u x . z i p (remove spaces between chars & download)

    APK Hosts File Engine 10++ SR-1 32/64-bit for Windows https://hosts-file.net/?s=Down... (DL link @ bottom)

    Soon for MacOS too (I just got a NEW Mac-Mini to port it there too)... apk

  48. Re:Same old mistakes, made again and again and aga by Aighearach · · Score: 1

    The frog stuff is a weird myth, not a real thing.

    That the story you're repeating claims to be based on something real is part of the myth, as with most myths.

    The frog stuff is a weird myth, not a real thing.