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
t's kind of an asshole move. It's like calling tech support and saying "I am a software developer, I know what I am doing." That may or may not actually be the case, but you sound like a douche regardless of whether you are competent or not.
Since I was a software developer, I did this on occasion when I didn't want to be bothered by the stupid questions of "did you reboot your computer" or other such checklist nonsense, or if I needed to get to the next tier because I knew that the first level dweebs weren't going to have a clue. The primary intent is for them to realize they're talking with someone who actually knows a bit about the issue. It's like every time I have to call the cable company and they want to run through the checklist of cycling power to my modem when I already checked that myself.
I know the intent. It frustrates the tech on the other end, though, as they don’t really know what needs to be done but can’t just escalate you like that. They have no choice but to follow the script. I’ve tried switching to telling them the things I have done on my own to attempt to fix and diagnose the issue. I am not 100% positive, but I think it goes over better. I have a few friends that manage US based tech support staff, I’ll try and remember to ask them about that approach. It’s frustrating to deal with but the people who are trying to help you can’t assume that you’ve tried everything on their script. It could quite literally get them fired.
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.
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
he was able to prove tickets were being written for those who legally pass through the lights. This means the city was going to lose money and the camera company was going to lose money too if changes were made. They had to do what they could to discredit and shut him up. It did not work.
The NHTSA has certain rules and regulations that you have to follow in order to get state funding for interstates and things of that nature. The best way to fight something like this is to file a civil lawsuit against the municipality and the company involved. If a judge rules against them and indicates that they are violating NHTSA regulations then the entire state would have to pay back the money it has received from the federal government in the time that it was not compliant. No, I am not a lawyer, but yes, I have had a lawyer use a traffic safety / engineering report to have a ticket thrown out because they had to withdraw the complaint or risk problems from the feds. Of course that was a criminal complaint against me, and they typically make these issues civil fines in order to avoid having to prove who was driving the vehicle.
The man did not overstep any authority by criticizing a system that malfunctions,
There was no question on that. Of course not.
and he described himself as an engineer in the course of actually documenting/supporting his work.
The clear intent of his use of the term was to impart special importance and credibility to his statements because he is "an engineer" and thus has more knowledge about such technical stuff than normal folks do. I don't think there is any question as to his intent in calling himself an engineer. Had his being an engineer been irrelevant to him and the issue at hand he would have not said it in the first place.
But that's not dealing with the issue the court dealt with. I have long questioned the ability of the state to keep people from claiming to be an engineer, since a lot of people work in jobs with that specific title while not requiring any certifications from the state.
Ahhh. But he did not say "Trust me, I am a Traffic Safety Engineer," did he? He did the equivalent of saying "You can call me Dr Jittles". Which would just imply that I have some sort of doctorate and am therefore possibly more educated than most people. (and no, I am not a doctor of any kind). But if I said "I am Jittles, Medical Doctor" then I would be claiming that I have specific type of education and knowledge of medicine. Those are two different things. He's merely trying to say that he feels that he analyzed this problem with the same sort of rigor than an engineer should use. It's kind of an asshole move. It's like calling tech support and saying "I am a software developer, I know what I am doing." That may or may not actually be the case, but you sound like a douche regardless of whether you are competent or not.
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
you exactly where the crust went, and when, and why.
Damn cat! I told it not to stand on top of the earth and push that crust onto the turtles. The little bastard likes to watch the look on my face as it slowly pushes the crust off the edge of the earth.
I don't want my thermostat connected to the internet.
Well, I can only tell you why I personally got a Wi-Fi thermostat. I used to travel a lot for work. Like A LOT. Some years I would fly over 100,000 miles. When you're not home often you don't really need to heat or AC on much. But it sucks coming home to a freezing cold or burning hot house at 3AM on a Friday night / Saturday morning. Sometimes I would forget to adjust the temps while I was gone. So I could turn the AC / heat off. Set it to temperatures that keep the house safe from mold or mildew. In fact, my thermostat can be set to turn on the AC if the humidity raises above a certain point. So what happens if I forget to turn the AC off? I do so from the airport. Don't want to come home to a 58 degree house after a long trip? Turn on the heat as soon as you touch down and the house will already be warming up before you get home. Is it necessary? No - I could live without it. But I found that I started saving over $100 a month in the summer and $20-30 a month in the winter. I've had that thermostat for 6 years now, so it has easily paid for itself.
As for security cameras, they can be helpful. However, I would personally put them on a completely separate network from your home network and use a single system to bridge them onto your network. Whether that is through RDP to view the video on a system that sits on both networks, or a VPN connection to that network, it protects your personal devices and privacy but still can potentially allow you to remotely view what's going on at home.
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.
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.
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.
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.
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.
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.
We also have kick-ass skiing and lots of other great outdoor activities.
And.... that is where you lost me. I agree with you that Vermont is a beautiful state but the skiing there is not kick-ass. There is nowhere on the East Coast that has kick-ass skiing. I love Burlington. If I could afford a summer home up there I'd probably love to live there for 4-5 months a year. But the snow isn't that amazing.
My kids are 5th, 7th, and 9th grade. We've felt that 2 hours of screen time (Netflix, computer/console gaming, tablet usage) was a healthy upper limit per day.
So what, because one person on slashdot says that you think its an industry trend now? I can’t say that I have ever asked an applicant that. If they did projects while in high school. Great. That doesn’t mean they are a good programmer. I happened to start working in the software field in high school as an intern. Do you want to know how many of my previous employers cared about that? None. Even when it was on my resume. They were more concerned about the things I learned and did at university over my actual work experience in high school. They literally did not care.
Hell yes, friends of friends - but still not "random people". Acquaintances, distant friends, whatever. Again, I don't know about your social circles, but my friends of friends I might not trust with my car, but I'd be surprised if they pulled a fast one on me over something like that. What did he pay them? $50 maybe?
What kind of person do you suppose would be willing to go through the time and effort to deal with this for $50? Especially when they supposedly lived hours away from him. The kind of person who is desperate for money and did not think that having the reaction be from a fake thief would hurt in any way. I am not saying that they're bad people. They are just in desperate circumstances or they would not be doing this for $50. Which is exactly why this guy should have known better than to offer money for this. I have a friend who lost his job and was without work for almost two years. He sold every single toy he had bought when the times were good - his boat, his motorcycle, everything. He would have definitely been willing to do this for $50 even if he had to ask a friend to fake the theft. And no, he is not a bad person. He was just desperate for cash.
Privatized medicine can work. There are clinics in the US that offer a menu of fixed-price services, and take direct payment (no insurance). No bureaucracy leads to reasonable prices - everybody wins.
The problem comes when the government intervenes too much. In the health insurance market, insisting that everyone must be covered, regardless of health problems or pre-existing conditions - that's no longer insurance, and has led to the problems the US is facing. Let the private insurance market work - it worked just fine for most people, most of the time, over many decades.
For people who cannot qualify for private insurance, the government can become the health care provider of last resort. That's basically where Medicare/Medicaid would come into play. Essential services only, no cosmetic or optional treatments. This is also where people would land, who get ill or injured, but couldn't be bothered to pay for insurance.
The situation in countries like the UK is actually not too dissimilar. The NHS provides health care for everyone, as long as you don't mind waiting months or years for anything that's not immediately life threatening. Meanwhile, there is a perfectly functional private insurance market for people who don't want to wait - the prices are reasonable, and coverage is good. As far as I can tell, the government basically ignores the private market - which is probably why it works.
You are living in a fantasy world. If the insurance companies had their way they would drop you the second you no longer became profitable, just as they often do for people with poor driving histories. The problem is that people often make poor choices that result in them being a bad driver. However, you can quickly become someone with preexisting conditions simply by becoming the unfortunate victim of a violent crime. It sounds like you and Mo Brooks are either the same person or best friends.
Ahhh so the truth comes out. You are cheer leading Lenovo because they give you free hardware and pay your bills.
I was wondering why you posted "only consumer manufacturer to take security seriously"
What a load a shit.
Lenovo does not pay my bills. They do not send me free hardware. Sometimes I need access to a customer's hardware to do specific work, that is not uncommon. That does not mean the hardware was A) free or that B) I get to keep it. And I work with other brands also. Some you've probably never heard of, and others that you know quite well. Did I not say that I work with many of these companies? Did I not say that it was my opinion? And I stand by what I said. I also indicated that they are NOT any more diligent when it comes to enterprise security. How much more clear do I need to be? Give me a break. And I think it's pretty clear from my post history that I have historically owned Apple computers, though my recent posts show that I am not exactly satisfied with hardware and software quality at Apple these days.
I would not be surprised if Lenovo was the only manufacturer shipping Windows 10 systems with 4GB of RAM and Secure Boot enabled.
Part of Microsoft "Designed for Windows" certification requires OEMs to ship their windows computers with Secure Boot enabled by default, and a switch for disabling it to be present in the BIOS.
Ah, yes. I forgot that has been a requirement since Windows 8. My relationship with Lenovo does not deal with Windows requirements.
Now while Lenovo may be the only company to "take security seriously" they are also the only company who couldn't code a Hello World example without including some system breaking bug. A company that has been in trouble with Microsoft updates before, who embedded firmware in their devices which called home, and a company where enabling Thunderbolt while running Linux caused their computer to be bricked (very secure a computer that can't even get to the BIOS screen), or installing Linux Kernel 4.13 caused the Lenovo BIOS to become read only (also great for security).
Fuck Lenovo and their piece of shit software / firmware.
I don’t ever see Lenovo code, I supply code to them for a hardware component that exists on most desktops, tablets, phones, laptops, and servers. If I deliver insecure code then Lenovo asks for patches for far more generations than any other manufacturer*. They license the code, though, so I can’t tell what they do with it after they get the fix. I don’t own any Lenovo products so I don’t track how long it takes for them to push fixes to their customers.
Lenovo is sending me some hardware this week for a project I am working on. I’ll pull the firmware off the board and see if I can detect anything unusual in their firmware.
*Other manufacturers are equally diligent for enterprise products. I can tell by the requests they make to me whether they are intending to patch an enterprise or a consumer product.
1. Vendor-specific (Lenovo only)
2. Dependent on the amount of memory (systems with less than 8 GB of RAM are affected)
3. Somehow related to Secure Boot (disabling Secure Boot is listed as a workaround)
And all the trouble is caused by patching a web browser (however deeply integrated with the operating system)? What the hell?
I work with a lot of these companies and Lenovo is, in my experience (and opinion), the only consumer grade manufacturer that takes security issues seriously. I would not be surprised if Lenovo was the only manufacturer shipping Windows 10 systems with 4GB of RAM and Secure Boot enabled.
The reason they're cheaper is because they're last years cards. Every year the card companies rotate out the older material. And then sell the warehouse cases to the dollar stores dirt cheap.
Heaven forbid there's a chance your middle/upper class customers commit a faux pas of giving someone a card they got last year? *gasp*
I can assure that this is not the case. I have a huge family and have literally had to recycle cards over the span of several years because Hallmark, et al keep those cards in rotation as long as they keep selling. I've gone through the entire card selection before and have had to reuse cards and cross my fingers that I remember who I sent that card to before.
Slashdot Mirror
Apple bought Freescale many years ago... engineers and all. Apple soc are based on Freescale technology.
I am aware of that. I was just pointing out that I believe that ARM does manufacture some CPUs, at least in the same sense the AMD manufactures them.
ARM does not make any CPUs. They have the design for them and license it out, for someone else to fab. In fact, Apple does its own silicon.
I believe that ARM does have some engineering samples fabbed for development purposes. But nothing that is commercialized by any means.
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
t's kind of an asshole move. It's like calling tech support and saying "I am a software developer, I know what I am doing." That may or may not actually be the case, but you sound like a douche regardless of whether you are competent or not.
Since I was a software developer, I did this on occasion when I didn't want to be bothered by the stupid questions of "did you reboot your computer" or other such checklist nonsense, or if I needed to get to the next tier because I knew that the first level dweebs weren't going to have a clue. The primary intent is for them to realize they're talking with someone who actually knows a bit about the issue. It's like every time I have to call the cable company and they want to run through the checklist of cycling power to my modem when I already checked that myself.
I know the intent. It frustrates the tech on the other end, though, as they don’t really know what needs to be done but can’t just escalate you like that. They have no choice but to follow the script. I’ve tried switching to telling them the things I have done on my own to attempt to fix and diagnose the issue. I am not 100% positive, but I think it goes over better. I have a few friends that manage US based tech support staff, I’ll try and remember to ask them about that approach. It’s frustrating to deal with but the people who are trying to help you can’t assume that you’ve tried everything on their script. It could quite literally get them fired.
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.
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
he was able to prove tickets were being written for those who legally pass through the lights. This means the city was going to lose money and the camera company was going to lose money too if changes were made. They had to do what they could to discredit and shut him up. It did not work.
The NHTSA has certain rules and regulations that you have to follow in order to get state funding for interstates and things of that nature. The best way to fight something like this is to file a civil lawsuit against the municipality and the company involved. If a judge rules against them and indicates that they are violating NHTSA regulations then the entire state would have to pay back the money it has received from the federal government in the time that it was not compliant. No, I am not a lawyer, but yes, I have had a lawyer use a traffic safety / engineering report to have a ticket thrown out because they had to withdraw the complaint or risk problems from the feds. Of course that was a criminal complaint against me, and they typically make these issues civil fines in order to avoid having to prove who was driving the vehicle.
The man did not overstep any authority by criticizing a system that malfunctions,
There was no question on that. Of course not.
and he described himself as an engineer in the course of actually documenting/supporting his work.
The clear intent of his use of the term was to impart special importance and credibility to his statements because he is "an engineer" and thus has more knowledge about such technical stuff than normal folks do. I don't think there is any question as to his intent in calling himself an engineer. Had his being an engineer been irrelevant to him and the issue at hand he would have not said it in the first place.
But that's not dealing with the issue the court dealt with. I have long questioned the ability of the state to keep people from claiming to be an engineer, since a lot of people work in jobs with that specific title while not requiring any certifications from the state.
Ahhh. But he did not say "Trust me, I am a Traffic Safety Engineer," did he? He did the equivalent of saying "You can call me Dr Jittles". Which would just imply that I have some sort of doctorate and am therefore possibly more educated than most people. (and no, I am not a doctor of any kind). But if I said "I am Jittles, Medical Doctor" then I would be claiming that I have specific type of education and knowledge of medicine. Those are two different things. He's merely trying to say that he feels that he analyzed this problem with the same sort of rigor than an engineer should use. It's kind of an asshole move. It's like calling tech support and saying "I am a software developer, I know what I am doing." That may or may not actually be the case, but you sound like a douche regardless of whether you are competent or not.
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
you exactly where the crust went, and when, and why.
Damn cat! I told it not to stand on top of the earth and push that crust onto the turtles. The little bastard likes to watch the look on my face as it slowly pushes the crust off the edge of the earth.
I don't want my thermostat connected to the internet.
Well, I can only tell you why I personally got a Wi-Fi thermostat. I used to travel a lot for work. Like A LOT. Some years I would fly over 100,000 miles. When you're not home often you don't really need to heat or AC on much. But it sucks coming home to a freezing cold or burning hot house at 3AM on a Friday night / Saturday morning. Sometimes I would forget to adjust the temps while I was gone. So I could turn the AC / heat off. Set it to temperatures that keep the house safe from mold or mildew. In fact, my thermostat can be set to turn on the AC if the humidity raises above a certain point. So what happens if I forget to turn the AC off? I do so from the airport. Don't want to come home to a 58 degree house after a long trip? Turn on the heat as soon as you touch down and the house will already be warming up before you get home. Is it necessary? No - I could live without it. But I found that I started saving over $100 a month in the summer and $20-30 a month in the winter. I've had that thermostat for 6 years now, so it has easily paid for itself.
As for security cameras, they can be helpful. However, I would personally put them on a completely separate network from your home network and use a single system to bridge them onto your network. Whether that is through RDP to view the video on a system that sits on both networks, or a VPN connection to that network, it protects your personal devices and privacy but still can potentially allow you to remotely view what's going on at home.
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.
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.
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.
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.
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.
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.
We also have kick-ass skiing and lots of other great outdoor activities.
And.... that is where you lost me. I agree with you that Vermont is a beautiful state but the skiing there is not kick-ass. There is nowhere on the East Coast that has kick-ass skiing. I love Burlington. If I could afford a summer home up there I'd probably love to live there for 4-5 months a year. But the snow isn't that amazing.
My kids are 5th, 7th, and 9th grade. We've felt that 2 hours of screen time (Netflix, computer/console gaming, tablet usage) was a healthy upper limit per day.
If your older ones end up taking up an interest in learning to program, do you plan to limit how much time they can spend on self-study of computer science on weekends and school vacations? When employers expect college graduates to have known more than one programming language before finishing high school, such a move could limit your kids' careers.
So what, because one person on slashdot says that you think its an industry trend now? I can’t say that I have ever asked an applicant that. If they did projects while in high school. Great. That doesn’t mean they are a good programmer. I happened to start working in the software field in high school as an intern. Do you want to know how many of my previous employers cared about that? None. Even when it was on my resume. They were more concerned about the things I learned and did at university over my actual work experience in high school. They literally did not care.
Hell yes, friends of friends - but still not "random people". Acquaintances, distant friends, whatever. Again, I don't know about your social circles, but my friends of friends I might not trust with my car, but I'd be surprised if they pulled a fast one on me over something like that. What did he pay them? $50 maybe?
What kind of person do you suppose would be willing to go through the time and effort to deal with this for $50? Especially when they supposedly lived hours away from him. The kind of person who is desperate for money and did not think that having the reaction be from a fake thief would hurt in any way. I am not saying that they're bad people. They are just in desperate circumstances or they would not be doing this for $50. Which is exactly why this guy should have known better than to offer money for this. I have a friend who lost his job and was without work for almost two years. He sold every single toy he had bought when the times were good - his boat, his motorcycle, everything. He would have definitely been willing to do this for $50 even if he had to ask a friend to fake the theft. And no, he is not a bad person. He was just desperate for cash.
Privatized medicine can work. There are clinics in the US that offer a menu of fixed-price services, and take direct payment (no insurance). No bureaucracy leads to reasonable prices - everybody wins.
The problem comes when the government intervenes too much. In the health insurance market, insisting that everyone must be covered, regardless of health problems or pre-existing conditions - that's no longer insurance, and has led to the problems the US is facing. Let the private insurance market work - it worked just fine for most people, most of the time, over many decades.
For people who cannot qualify for private insurance, the government can become the health care provider of last resort. That's basically where Medicare/Medicaid would come into play. Essential services only, no cosmetic or optional treatments. This is also where people would land, who get ill or injured, but couldn't be bothered to pay for insurance.
The situation in countries like the UK is actually not too dissimilar. The NHS provides health care for everyone, as long as you don't mind waiting months or years for anything that's not immediately life threatening. Meanwhile, there is a perfectly functional private insurance market for people who don't want to wait - the prices are reasonable, and coverage is good. As far as I can tell, the government basically ignores the private market - which is probably why it works.
You are living in a fantasy world. If the insurance companies had their way they would drop you the second you no longer became profitable, just as they often do for people with poor driving histories. The problem is that people often make poor choices that result in them being a bad driver. However, you can quickly become someone with preexisting conditions simply by becoming the unfortunate victim of a violent crime. It sounds like you and Mo Brooks are either the same person or best friends.
Ahhh so the truth comes out. You are cheer leading Lenovo because they give you free hardware and pay your bills.
I was wondering why you posted "only consumer manufacturer to take security seriously"
What a load a shit.
Lenovo does not pay my bills. They do not send me free hardware. Sometimes I need access to a customer's hardware to do specific work, that is not uncommon. That does not mean the hardware was A) free or that B) I get to keep it. And I work with other brands also. Some you've probably never heard of, and others that you know quite well. Did I not say that I work with many of these companies? Did I not say that it was my opinion? And I stand by what I said. I also indicated that they are NOT any more diligent when it comes to enterprise security. How much more clear do I need to be? Give me a break. And I think it's pretty clear from my post history that I have historically owned Apple computers, though my recent posts show that I am not exactly satisfied with hardware and software quality at Apple these days.
I would not be surprised if Lenovo was the only manufacturer shipping Windows 10 systems with 4GB of RAM and Secure Boot enabled.
Part of Microsoft "Designed for Windows" certification requires OEMs to ship their windows computers with Secure Boot enabled by default, and a switch for disabling it to be present in the BIOS.
Ah, yes. I forgot that has been a requirement since Windows 8. My relationship with Lenovo does not deal with Windows requirements.
Now while Lenovo may be the only company to "take security seriously" they are also the only company who couldn't code a Hello World example without including some system breaking bug. A company that has been in trouble with Microsoft updates before, who embedded firmware in their devices which called home, and a company where enabling Thunderbolt while running Linux caused their computer to be bricked (very secure a computer that can't even get to the BIOS screen), or installing Linux Kernel 4.13 caused the Lenovo BIOS to become read only (also great for security).
Fuck Lenovo and their piece of shit software / firmware.
I don’t ever see Lenovo code, I supply code to them for a hardware component that exists on most desktops, tablets, phones, laptops, and servers. If I deliver insecure code then Lenovo asks for patches for far more generations than any other manufacturer*. They license the code, though, so I can’t tell what they do with it after they get the fix. I don’t own any Lenovo products so I don’t track how long it takes for them to push fixes to their customers.
Lenovo is sending me some hardware this week for a project I am working on. I’ll pull the firmware off the board and see if I can detect anything unusual in their firmware.
*Other manufacturers are equally diligent for enterprise products. I can tell by the requests they make to me whether they are intending to patch an enterprise or a consumer product.
So according to https://support.microsoft.com/... it's:
1. Vendor-specific (Lenovo only) 2. Dependent on the amount of memory (systems with less than 8 GB of RAM are affected) 3. Somehow related to Secure Boot (disabling Secure Boot is listed as a workaround)
And all the trouble is caused by patching a web browser (however deeply integrated with the operating system)? What the hell?
I work with a lot of these companies and Lenovo is, in my experience (and opinion), the only consumer grade manufacturer that takes security issues seriously. I would not be surprised if Lenovo was the only manufacturer shipping Windows 10 systems with 4GB of RAM and Secure Boot enabled.
The reason they're cheaper is because they're last years cards. Every year the card companies rotate out the older material. And then sell the warehouse cases to the dollar stores dirt cheap.
Heaven forbid there's a chance your middle/upper class customers commit a faux pas of giving someone a card they got last year? *gasp*
I can assure that this is not the case. I have a huge family and have literally had to recycle cards over the span of several years because Hallmark, et al keep those cards in rotation as long as they keep selling. I've gone through the entire card selection before and have had to reuse cards and cross my fingers that I remember who I sent that card to before.