NSA's BIOS Backdoor a.k.a. God Mode Malware(resources.infosecinstitute.com)
resources.infosecinstitute.com
NSA's BIOS Backdoor a.k.a. God Mode Malware
http://resources.infosecinstitute.com/nsa-bios-backdoor-god-mode-malware-deitybounce/?Print=Yes
68 comments
It appears this article is a confirmation of that.
https://sites.google.com/site/pinczakko/nsa-bios-backdoor-a-...
It took a while to find the original, it's a PDF rather than a web page and it was plagiarized within days of being published, google picked up on the plagiarized copy before it ever saw the original by the looks of it.
https://sites.google.com/site/pinczakko/nsa-bios-backdoor-a-...
It took a while to find the original, it's a PDF rather than a web page and it was plagiarized within days of being published, google picked up on the plagiarized copy before it ever saw the original by the looks of it.
I am not sure how you get from the PDF to the confirmation. The first page of the PDF says it is from “Infosec Institute” and “Darmawan Salihun”. If you want to show plagiarism, should you not be linking to a version that has the same contents but with different authors?
Darmawan Salihun is the author of both and according to his LinkedIn page:
BIOS/UEFI Security Researcher InfoSec Institute June 2012 – Present (2 years 3 months)
Plus the OP's article was published before that PDF (January Vs. Feb).
BIOS/UEFI Security Researcher InfoSec Institute June 2012 – Present (2 years 3 months)
Plus the OP's article was published before that PDF (January Vs. Feb).
On that site the author is the same one as listed on the infosec article, and they claim he's a researcher for ISI.
It's interesting that this malware only targets certain models of Dell PowerEdge servers with particular RAID controllers. Since the average terrorist isn't likely to be using one of these, it would seem that the purpose of this malware is for spying on businesses or government agencies.
I think the biggest "scandal" we haven't seen the leakers talk about is the intelligence for US business interests.
As in the NSA literally going after foreign businesses and then turning around, and giving that information 1:1 to US corporations. That should be a pretty big scandal considering how much the US prides itself on being a capitalist market (i.e. survival of the fitness, not best politically connected).
But the US has a long history of this, and frankly at least they stopped starting wars in South American on the behest of US businesses so that's something...
As in the NSA literally going after foreign businesses and then turning around, and giving that information 1:1 to US corporations. That should be a pretty big scandal considering how much the US prides itself on being a capitalist market (i.e. survival of the fitness, not best politically connected).
But the US has a long history of this, and frankly at least they stopped starting wars in South American on the behest of US businesses so that's something...
Thanks to reveals like Echelon (https://en.wikipedia.org/wiki/ECHELON), every big/strategic (e.g. energy/arms) business in Europe has been aware of this since the late 80s (at least). For instance in the 90s, a common strategy when negotiating with US companies was to send misinformation via email or fax internally knowing that the NSA would pass it on. From the results of the negotiations it appeared that the NSA were not aware that they were being played in this way.
Anyway, so that's why I think you're not hearing too much about that scandal - it comes as no shock to anyone it affects.
Anyway, so that's why I think you're not hearing too much about that scandal - it comes as no shock to anyone it affects.
In the intro the author explains that the likely targets are client computers connecting to these servers. Later he explains how the specific hardware requirements (PowerEdge gen 8 & 9 + PERC RAID controller) are likely due to the storage requirements of the malware dropper. These generations of PowerEdge servers were very common in many datacenters, so it makes a lot of sense to target them. It also seems likely that other makes and models have been targeted by similar malware components, however this article is specifically about DEITYBOUNCE.
"National security" was never just about terrorists. It is also spying on foreign governments, companies and other organizations, most of whom would be running servers.
Or it was a proof of concept meant to remain obscure?
Are you well-acquainted with the census of popular server hardware among terrorists organizations? If so, please elaborate. If not, tell us what could possibly lead you to write such a comment.
I get the impression that most violent terrorist groups are rather low-tech and are not using _any_ server hardware. If you're aware of terrorists routinely operating DCs or co-locating servers, feel free to correct my understanding.
I wouldn't be surprised if ISIS would use more advanced and up to date server hardware than most corporations.
This is fot the 'hackers' such as Anonymous I suppose.
Maybe he is not a citizen of the US and therefore believes that the main aim of the NSA is industrial espionage.
Here's another reason why using a free BIOS like Coreboot is a great idea - if malware attempts to reflash it with an infected copy of presumably the original proprietary BIOS, it will be very, very obvious.
Another "tamper detection" idea, if you're OK with using proprietary BIOS and/or Coreboot isn't supported, is to add a small piece of code to the existing BIOS that simply hashes the ROM contents and prints out a human-readable string to the boot screen based on that. If it goes missing or changes, then you can suspect something happened. Of course, the trick is to not have everyone doing this with the same code, or backdoors will just detect and spoof it. I modded the BIOS of an old machine I have to do this, it prints out "Customised by {my handle}".
Another "tamper detection" idea, if you're OK with using proprietary BIOS and/or Coreboot isn't supported, is to add a small piece of code to the existing BIOS that simply hashes the ROM contents and prints out a human-readable string to the boot screen based on that. If it goes missing or changes, then you can suspect something happened. Of course, the trick is to not have everyone doing this with the same code, or backdoors will just detect and spoof it. I modded the BIOS of an old machine I have to do this, it prints out "Customised by {my handle}".
This is an interesting idea, but don't try and expect humans to notice some random string (i.e. fingerprint, checksum). Instead, using something like OpenSSH's "randomart"[1]. It can be made such that any small change makes a totally different blob pattern (BIG bonus points for using COLOR!).
Possibly, this could even be chained into the background of the main OS load sequence, such that you see something like a Perlin-style colorful noise pattern during the longest part of the boot sequence. This could even hash other parts of the loader besides the BIOS, too.
The idea being that you (probably) won't notice if
http://cs263.markaoyama.com/img/p5_abs_perlin_5_gens.PNG
changes into
http://cs263.markaoyama.com/img/p5_perlin_5_gen.PNG
(images taken from a very brief GIS of random Perlin noise articles)
There are many alternatives. The key here is to engage the human visual system. Proof of why this work: the popularity of font-lock-mode.
[1] http://superuser.com/questions/22535/what-is-randomart-produ...
Possibly, this could even be chained into the background of the main OS load sequence, such that you see something like a Perlin-style colorful noise pattern during the longest part of the boot sequence. This could even hash other parts of the loader besides the BIOS, too.
The idea being that you (probably) won't notice if
801EF9B138222F39EB2907634BC7FD47F9151919
40AE7CE2796FB14526ABB92B67BC0F1423B85B96
http://cs263.markaoyama.com/img/p5_abs_perlin_5_gens.PNG
changes into
http://cs263.markaoyama.com/img/p5_perlin_5_gen.PNG
(images taken from a very brief GIS of random Perlin noise articles)
There are many alternatives. The key here is to engage the human visual system. Proof of why this work: the popularity of font-lock-mode.
[1] http://superuser.com/questions/22535/what-is-randomart-produ...
TBH, I don't think this would be very effective at all. I manage hundreds of servers for businesses, and if I ever see a Dell splash screen it's purely by accident. With basically everyone using virtualization, it's a long time between reboots for physical servers to begin with. And when I do need to reboot the physical server, I'm usually sitting at home in my underwear, not looking at the console. We can manage most of the BIOS-level settings through Dell-provided tools, so even when we change BIOS settings, we don't go into the BIOS.
In my IT experience, anything requiring manual human checking basically doesn't get done after the first handful of iterations. If it needs to be reliable, it needs to be automated. My best guess is, you can install a package from Dell to enable BIOS info to be pulled via WMI (Dell OMCI I think). You can set all of your BIOS asset tags to some unique value (per machine) and if it changes, your monitoring software will see it and alert you. I'm not sure how easy this would be to spoof though. It might be trivial.
Fortunately, most of the models they mention have been out of warranty for some years now, and most businesses choose to upgrade to a supported model. For businesses who chose not to upgrade to supported models, it's usually a reflection of the immature management in charge of the business, meaning they make poor decisions in many areas, so a BIOS hack is way down the list of potential problems for them.
In my IT experience, anything requiring manual human checking basically doesn't get done after the first handful of iterations. If it needs to be reliable, it needs to be automated. My best guess is, you can install a package from Dell to enable BIOS info to be pulled via WMI (Dell OMCI I think). You can set all of your BIOS asset tags to some unique value (per machine) and if it changes, your monitoring software will see it and alert you. I'm not sure how easy this would be to spoof though. It might be trivial.
Fortunately, most of the models they mention have been out of warranty for some years now, and most businesses choose to upgrade to a supported model. For businesses who chose not to upgrade to supported models, it's usually a reflection of the immature management in charge of the business, meaning they make poor decisions in many areas, so a BIOS hack is way down the list of potential problems for them.
> In my IT experience, anything requiring manual human checking basically doesn't get done
I fully agree - that why I like this idea; it doesn't rely on humans actively doing something, and instead engages the subconscious. Because our brain is constantly making predictions about everything we perceive, we tend to notice (without trying) if something subtly violates those predictions. We see this effect when people describe how they felt something was "off" or "wrong" before some big event. They probably did see something important, but not enough to recognize it or parse it consciously.
Engaging the warning system that our fight-or-flight reflexes - which is very effective at processing visual sense input - is probably one of the more practical ways of getting past in this "humans won't bother" category.
Also, a visual-hash isn't really trying to be perfect anyway. It's just a trick that would be very easy to implement. It won't get anywhere close to catching all attacks. It would probably catch more than our current strategy of doing nothing. When you start from 0, any improvement helps. The only reason not to do this kind of scheme would be if it raised the costs, but I doubt that would be a problem given how much headroom we have in modern hardware.
I fully agree - that why I like this idea; it doesn't rely on humans actively doing something, and instead engages the subconscious. Because our brain is constantly making predictions about everything we perceive, we tend to notice (without trying) if something subtly violates those predictions. We see this effect when people describe how they felt something was "off" or "wrong" before some big event. They probably did see something important, but not enough to recognize it or parse it consciously.
Engaging the warning system that our fight-or-flight reflexes - which is very effective at processing visual sense input - is probably one of the more practical ways of getting past in this "humans won't bother" category.
Also, a visual-hash isn't really trying to be perfect anyway. It's just a trick that would be very easy to implement. It won't get anywhere close to catching all attacks. It would probably catch more than our current strategy of doing nothing. When you start from 0, any improvement helps. The only reason not to do this kind of scheme would be if it raised the costs, but I doubt that would be a problem given how much headroom we have in modern hardware.
This is nearly a good idea, except that by adding a random string and hashing it a few times, you can get an image that is approximately the same. Its might be reasonable to assume the NSA gets 100,000 to 1,000,000 attempts at low expense, of which at least a few hundred will be a similar color, and one of those will have a similar-enough pattern that people are less likely to notice.
It does create another level of protection for the user, and another hurdle for the attacker, but it still requires user diligence.
It does create another level of protection for the user, and another hurdle for the attacker, but it still requires user diligence.
Seeing as we are starting from 0 (no verification at all), any improvement would be a benefit. This would simply be a cheap and easy way to catch "some" attacks.
Also, see my response to halfcat in a neighboring post.
Also, see my response to halfcat in a neighboring post.
Hello, I've put quick ASCII to Pixels converter http://sergeykish.com/randomart
Already looks fun, yet image magic depixelizer makes it awesome. I think once converted to custom tag it may gain adoption <fingerprint>05:1e:1e:c1:ac:b9:d1:1c:6a:60:ce:0f:77:6c:78:47</fingerprint>
Already looks fun, yet image magic depixelizer makes it awesome. I think once converted to custom tag it may gain adoption <fingerprint>05:1e:1e:c1:ac:b9:d1:1c:6a:60:ce:0f:77:6c:78:47</fingerprint>
I actually don't know how this would become obvious. Do you look at your server screens while they boot? Any attempt to checksum the BIOS from the operating system could be easily bypassed by simply regurgitating the OEM BIOS if anyone reads it.
Do you look at your server screens while they boot?
Long enough to see the POST screen where I put the message:
Ditto for the NSA trying to flash a backdoored Coreboot: they would have to know exactly the customisations I made to my BIOS to replicate them, and if they did, then I'm probably pwned anyway. Backdoors in an offboard option ROM would certainly avoid modifying the BIOS, but I guess a similar mechanism could be used to customise one to easily detect its modification.
Long enough to see the POST screen where I put the message:
Award Modular BIOS v4.51PG ==Customised by XXXXXXXX==
Ditto for the NSA trying to flash a backdoored Coreboot: they would have to know exactly the customisations I made to my BIOS to replicate them, and if they did, then I'm probably pwned anyway. Backdoors in an offboard option ROM would certainly avoid modifying the BIOS, but I guess a similar mechanism could be used to customise one to easily detect its modification.
Coreboot is a great idea, and I actually considered using it, but the project looks woefully under-powered for the role it hopes to play: the list of supported devices is very sparse and consists of really old models, mostly; even the supported systems have issues and/or untested functionality. http://www.coreboot.org/Supported_Motherboards
I haven't looked into the relationship Chromebooks have with Coreboot: supposedly, Chromebooks use Coreboot, but how is it possible that they restrict the usage of OS to a signed one: do Chromebooks use modified Coreboot? And why is some models' status listed as "Unknown" in Supported Motherboards list?
So, I would love to use Coreboot and would actually consider going into some reasonable trouble to make it work on my hardware (including actually picking hardware that it supports), but I really don't see how it would be usable even for an enthusiast, and I don't see the situation changing anytime soon.
I haven't looked into the relationship Chromebooks have with Coreboot: supposedly, Chromebooks use Coreboot, but how is it possible that they restrict the usage of OS to a signed one: do Chromebooks use modified Coreboot? And why is some models' status listed as "Unknown" in Supported Motherboards list?
So, I would love to use Coreboot and would actually consider going into some reasonable trouble to make it work on my hardware (including actually picking hardware that it supports), but I really don't see how it would be usable even for an enthusiast, and I don't see the situation changing anytime soon.
They restrict use to a signed OS through their payload. coreboot only does hardware initialization, then passes control to other software in flash that handles loading the OS and policy surrounding it.
As for the "Supported Motherboards" list, it's automatically generated from reports that are sent in through a tool. Google doesn't do that (yet?), so they're not listed as supported. Still better than our old, manually maintained list, that got stale fast (with false positives, which are much more annoying from a support standpoint than false negatives)
As for the "Supported Motherboards" list, it's automatically generated from reports that are sent in through a tool. Google doesn't do that (yet?), so they're not listed as supported. Still better than our old, manually maintained list, that got stale fast (with false positives, which are much more annoying from a support standpoint than false negatives)
Chromebooks/Chromeboxes use a forked Coreboot:
https://chromium.googlesource.com/chromiumos/third_party/cor...
Most of the Chromebook/box devices have a physical write-protect that can be removed allowing re-flashing with modified firmware.
https://chromium.googlesource.com/chromiumos/third_party/cor...
Most of the Chromebook/box devices have a physical write-protect that can be removed allowing re-flashing with modified firmware.
ok, so it means that even for a Chromebook, Coreboot support is not a given.
All x86 Chromebooks (except for the CR48 prototype) use coreboot.
For ARM Chromebooks the situation is more complicated - coreboot's ARM support was developed by the Chromebook firmware developers but it seems they missed a deadline or two (no surprise with an architecture bringup), so some of those devices ship with u-boot while coreboot does have support for them.
For ARM Chromebooks the situation is more complicated - coreboot's ARM support was developed by the Chromebook firmware developers but it seems they missed a deadline or two (no surprise with an architecture bringup), so some of those devices ship with u-boot while coreboot does have support for them.
In "Latest known good" column in "Supported Motherboards/Laptops" it says "Unknown" for 5 Intel x86 Chromebooks. http://www.coreboot.org/Supported_Motherboards#Laptops
I understand it means that to the best of Coreboot developers' knowledge (and who knows better than them, right?) noone ever tried to run open-source builds of Coreboot on these models. Consequently, it is overwhelmingly likely that Coreboot (the open-source version that we have access to, not the one in the Googleplex) won't work. Am I mistaken?
I considered using C720 Chromebook with open-source Coreboot, but, alas, it says "Unknown" for it, too.
I understand it means that to the best of Coreboot developers' knowledge (and who knows better than them, right?) noone ever tried to run open-source builds of Coreboot on these models. Consequently, it is overwhelmingly likely that Coreboot (the open-source version that we have access to, not the one in the Googleplex) won't work. Am I mistaken?
I considered using C720 Chromebook with open-source Coreboot, but, alas, it says "Unknown" for it, too.
No, it means that noone bothered to send in reports.
http://johnlewis.ie/ provides non-Google coreboot images for many Chromebooks. They claim having tested each of their binaries and from looking at the support forums, they have a fair share of users.
Also, the "Googleplex version" of coreboot can be found at https://chromium-review.googlesource.com/#/q/project:chromiu... (though it can be hard to pinpoint any given released firmware to a concrete commit there - they're working on it)
http://johnlewis.ie/ provides non-Google coreboot images for many Chromebooks. They claim having tested each of their binaries and from looking at the support forums, they have a fair share of users.
Also, the "Googleplex version" of coreboot can be found at https://chromium-review.googlesource.com/#/q/project:chromiu... (though it can be hard to pinpoint any given released firmware to a concrete commit there - they're working on it)
If noone bothered to send in reports, we cannot assume it is really working, can we? After all, without testing, software most certainly doesn't work.
Who is this John Lewis guy and why isn't his work the part of the official Coreboot images?
Who is this John Lewis guy and why isn't his work the part of the official Coreboot images?
There are no official coreboot images.
John's images are kind of a coreboot distribution, as is libreboot (http://www.libreboot.org/)
John's images are kind of a coreboot distribution, as is libreboot (http://www.libreboot.org/)
What you really need is
- A piece of hardware under the user's control that provides cyptographically secure key material that allows the BIOS to boot.
- Attestation by the booted thing that it is intact and untampered with.
Both of these need to be inspectable by the user. For the former you can use a dongle with a key on it, and this is probably testably secure by an end-user (we can talk about trusting silicon and your tools, but if you use multiple platforms and toolsets for verification that's probably pretty reasonable).
Knowing that the "enemy side" (the BIOS) hasn't been suborned is pretty hard and requires hardware-level support that you're not going to see outside of video game consoles.
For the truly paranoid, your best bet is to use a computer that has no physically attached peripherals that you can't monitor (e.g., USB). So, USB-attached network adapters and so forth.
This stuff is hard.
- A piece of hardware under the user's control that provides cyptographically secure key material that allows the BIOS to boot.
- Attestation by the booted thing that it is intact and untampered with.
Both of these need to be inspectable by the user. For the former you can use a dongle with a key on it, and this is probably testably secure by an end-user (we can talk about trusting silicon and your tools, but if you use multiple platforms and toolsets for verification that's probably pretty reasonable).
Knowing that the "enemy side" (the BIOS) hasn't been suborned is pretty hard and requires hardware-level support that you're not going to see outside of video game consoles.
For the truly paranoid, your best bet is to use a computer that has no physically attached peripherals that you can't monitor (e.g., USB). So, USB-attached network adapters and so forth.
This stuff is hard.
Why would the malware not hash the current BIOS and show you the same hash?
If the page author reads this: I find the delayed sidebar animation very annoying. Also so distracting I'd say the "Want to learn more?" boxes are less effective this way.
Haha, same here, I nuked it with a display:none to #sidebar because it was so annoying and I wanted to finish the article.
Safari's Reader Mode is a godsend for these sites.
So, I was making the correct determination when requiring that all server and desktop hardware puchased by my companies originate from BRICS nations. Avoiding dell/cisco/juniper/hp for networking equipment, and opting for Custom RK3188 and AllWinner A23-based routers/switches and desktop thin clients running (Debian/Angstrom) linux are gonna throw more than one wrench in any surveillance plans.
I wonder how many exploits the Five Eyes have for Tahoe-LAFS running on LVM disks. I'm betting on very few.
I wonder how many exploits the Five Eyes have for Tahoe-LAFS running on LVM disks. I'm betting on very few.
Isn't this changing the devil you know for one you don't? Instead of potentially having NSA spy on your org, you have potential of China and Russia doing the spying?
Or is there solid evidence that these countries aren't engaging in the same stuff as the NSA?
Or is there solid evidence that these countries aren't engaging in the same stuff as the NSA?
> Isn't this changing the devil you know for one you don't?
I don't think so.
How likely is it that China spying on you will actually impact your life, if you're living somewhere in the US or Europe?
Compare this to How likely is it that the US spying on you will actually impact your life, if you're living somewhere in the US or Europe...
I mean sure, this may be a relevant consideration for actual terrorists, but hardly for "regular" people that are more concerned about mundane details like their unhealthy dietary habbits being leaked to insurance companies, or their downloading of youtube videos being leaked to copyright holders.
I don't think so.
How likely is it that China spying on you will actually impact your life, if you're living somewhere in the US or Europe?
Compare this to How likely is it that the US spying on you will actually impact your life, if you're living somewhere in the US or Europe...
I mean sure, this may be a relevant consideration for actual terrorists, but hardly for "regular" people that are more concerned about mundane details like their unhealthy dietary habbits being leaked to insurance companies, or their downloading of youtube videos being leaked to copyright holders.
Well, one of the risks that you face in a state-sponsored advisory is industrial espionage, and that is as likely to come from China [1] as it is coming from the NSA [2].
[1] http://money.cnn.com/2014/05/20/news/china-espionage-busines... [2] http://www.theguardian.com/world/2013/sep/09/nsa-spying-braz...
[1] http://money.cnn.com/2014/05/20/news/china-espionage-busines... [2] http://www.theguardian.com/world/2013/sep/09/nsa-spying-braz...
This may just be paranoia on my part, but wouldn't being a target of industrial espionage by the Chinese make you already important/big enough to have the NSA working for rather than against you?
Not if you're in a competing country to both US and China. The world is bigger than the US :-)
Engineers have to work with what they have.
Do you disagree that he made the right decision?
Is there solid evidence that these countries are engaging in the same stuff as the NSA?
Do you disagree that he made the right decision?
Is there solid evidence that these countries are engaging in the same stuff as the NSA?
Yes, I disagree. If there's an almost guaranteed chance that my org will be spied on, I would rather have the US do the spying. Unlike a BRICS country, at least the US has the occasional Snowden to shed light on things. The resulting scandal may do little to change the status quo, but it'll lead to a discussion and maybe a civil suit my company can win.
I have never heard of a similar public leaker from Russia or China (I imagine those people just quickly get disappeared).
As for BRICS country spying, we have some very solid evidence that China is engaging in cyber espionage of both US military and corporate targets.
I have never heard of a similar public leaker from Russia or China (I imagine those people just quickly get disappeared).
As for BRICS country spying, we have some very solid evidence that China is engaging in cyber espionage of both US military and corporate targets.
If you are working on US based consumer web site, spying by NSA could be much more harmful than spying by China or Russia for vast majority of users. NSA is known to provide leads to police that then reconstructed evidence to exclude any links to NSA and still arrest/harass the person. There are people who are not national security risk in US jails because of NSA (mostly drug busts). BRICS countries have zero interest whether you smoke dope in your free time and won't rat you out to local police.
PS. I am not arguing that they should not be in jail. Just that NSA used semi-legal (waterboarding!=torture kind) methods to obtain initial leads.
PS. I am not arguing that they should not be in jail. Just that NSA used semi-legal (waterboarding!=torture kind) methods to obtain initial leads.
What if dissidents are using your service because it's outside their country of origin and they get disappeared because of it?
As I said it's better to be located outside of country where majority of your users are. If your service targets american market, you can minimize risk to majority of your users by locating service outside of US. Dissident disappearing is mostly red herring - people disappear in US too (Guantanomo).
There was plenty of solid evidence of those countries spying on US citizens long before there was solid evidence of the US spying on US citizens.
I would be surprised if India, China, or Russia did not have similar sorts of surveillance programs.
But, I think you're right, you're unlikely to be caught in dragnet-style surveillance by the Five Eyes nations, but this style of attack sounds like it has to be targeted.
But, I think you're right, you're unlikely to be caught in dragnet-style surveillance by the Five Eyes nations, but this style of attack sounds like it has to be targeted.
> requiring that all server and desktop hardware puchased by my companies originate from BRICS nations
How exactly did you do this? Obviously the company assembling the pieces (like CPUs and chipsets) into the final PC isn't really the issue, but rather the companies producing those pieces - and virtually none of them are outside the US, seeing as how there's only Intel (and maybe AMD).
Your idea sounds good, and I'd like to adopt it, but I just don't see how, with x86 hardware.
Then again, maybe this'll be a major selling point for ARM-based Servers and Desktops at some point in the future? :x
How exactly did you do this? Obviously the company assembling the pieces (like CPUs and chipsets) into the final PC isn't really the issue, but rather the companies producing those pieces - and virtually none of them are outside the US, seeing as how there's only Intel (and maybe AMD).
Your idea sounds good, and I'd like to adopt it, but I just don't see how, with x86 hardware.
Then again, maybe this'll be a major selling point for ARM-based Servers and Desktops at some point in the future? :x
Get on alibaba.com, and find a supplier. Most allow customization of the boards you purchase. And the above-mentioned chipsets have full Linux support. Getting arm-based boards with 4+ 10gigE ports is easier than you'd think.
The desktops are all arm-based thin clients running X servers with all apps hosted remotely. If a device fails, plug in another one and keep working.
Richard Stallman abandoned Five Eyes-based chipsets for the same reason, long before I ever did. We should look to him more for inspiration on how to remain free during these draconian times.
The desktops are all arm-based thin clients running X servers with all apps hosted remotely. If a device fails, plug in another one and keep working.
Richard Stallman abandoned Five Eyes-based chipsets for the same reason, long before I ever did. We should look to him more for inspiration on how to remain free during these draconian times.
What about this exploit really requires a US supply chain? Why do you believe that the Five Eyes have fewer exploits for hardware originating from BRICS nations? Don't intelligence agencies have explicit missions to spy on those countries?
If you think that because you are running less popular hardware, that the NSA wouldn't bother obtaining exploits for them, you may be right. In that case, though, you're simply making a popularity trade-off. (And it is a trade-off, more popular hardware is more popular for a reason.)
If you think that because you are running less popular hardware, that the NSA wouldn't bother obtaining exploits for them, you may be right. In that case, though, you're simply making a popularity trade-off. (And it is a trade-off, more popular hardware is more popular for a reason.)
From all documents released by snowden thus far, it is clear that the Five Eyes are targeting their own supply chains. They're using arm7 and arm9 chips in their hardware bugs, but it's clear that they have no focus at all on arm exploits.
Both the RK3xxx and A23 chips are fully supported in Linux 3.16, so I see no trade-off. Just low wattage and a bit of peace of mind that my government has to custom-tailor exploits for me and my companies, which isn't very cost-effective. :-)
Both the RK3xxx and A23 chips are fully supported in Linux 3.16, so I see no trade-off. Just low wattage and a bit of peace of mind that my government has to custom-tailor exploits for me and my companies, which isn't very cost-effective. :-)
Dell especially seems to be targeted a lot by NSA - easy target? Or something more?
Edward Snowden worked for Dell, maintaining NSA infrastructure. They NSA is deep into Dell, easy access to specs and maybe the NSA even engineered those backdoors themselves.
In "the good old days" before the race to the bottom that value-engineered every penny of cost out of a product, motherboards and expansion cards had onboard hardware jumpers or switches that protected the ROM from modification. It was impossible to update the BIOS without opening the case and physically moving the jumper.
But that jumper cost money, and perhaps more importantly confused half the sysadmins and users out there. So the jumper is gone. Any program that knows the magic output sequence can overwrite the firmware. We're relying on security through obscurity to save us.
And if I'm Dell, I'm thinking: Hey, what about HP? What about IBM? Why single me out? Most if not all of these computers are vulnerable to similar attacks.
But that jumper cost money, and perhaps more importantly confused half the sysadmins and users out there. So the jumper is gone. Any program that knows the magic output sequence can overwrite the firmware. We're relying on security through obscurity to save us.
And if I'm Dell, I'm thinking: Hey, what about HP? What about IBM? Why single me out? Most if not all of these computers are vulnerable to similar attacks.
Nothing suprising, just take a look at the Intel iAMT ;)
Forget about AMT, it's a major pain to enable even if you need to. The Computrace "Laptop LoJack" application is trivial to activate has been embedded in most major OEM bios for years.
http://www.absolute.com/en/partners/bios-compatibility.aspx
It's capable of phoning home, deleting or replacing files on the operating system and wiping out the system. It can persist across re installations of support operating systems. When combined with AMT features it can permanently brick the device as well.
http://www.absolute.com/en/partners/bios-compatibility.aspx
It's capable of phoning home, deleting or replacing files on the operating system and wiping out the system. It can persist across re installations of support operating systems. When combined with AMT features it can permanently brick the device as well.
Reading this sentence from the article reminded me of Computrace:
because even a rudimentary NTFS driver would require at least several tens of kilobytes of space when compressed
The Computrace option ROM is a little over 20KB (compressed), yet it contains much of the functionality of the NSA backdoor described in the article - including write-support drivers for FAT/FAT32/NTFS.
http://securelist.com/analysis/publications/58278/absolute-c...
So the reason for using the RAID controller's option ROM may be for stealth instead of size restrictions, and it also means that, if the NSA can tell Absolute what to do, they already have a BIOS-level backdoor into nearly everyone's machines.
because even a rudimentary NTFS driver would require at least several tens of kilobytes of space when compressed
The Computrace option ROM is a little over 20KB (compressed), yet it contains much of the functionality of the NSA backdoor described in the article - including write-support drivers for FAT/FAT32/NTFS.
http://securelist.com/analysis/publications/58278/absolute-c...
So the reason for using the RAID controller's option ROM may be for stealth instead of size restrictions, and it also means that, if the NSA can tell Absolute what to do, they already have a BIOS-level backdoor into nearly everyone's machines.
Offtopic, but I've been trying to get into my Thinkpad X1's AMT setup - I hit ctrl-P on boot but it is missing some kind of file and just boots normally. Anyone know anything about it?
I could never work in computer security
http://attrition.org/errata/charlatan/infosec_institute/