The real solution
A physical switch that disables all writes to the flash memory.
Yes, I know that's inconvenient, but if you're using really important hardware it's the nearest thing you'll get to safe... for some undefined value of 'safe'.
ESET eggheads have shed more light on the Unified Extensible Firmware Interface (UEFI) rootkit being used by the Kremlin's Fancy Bear hacking crew. Dubbed Lojax, the software nasty embeds itself within the motherboard firmware of infected Windows PCs, allowing it to run as soon as the machine is powered up or reset, allowing …
From previous article:-
Though designed to protect laptops from theft, LoJack implements only minimal security to safeguard its own data.
So 2009, hacker convention pointed out LoJack had an XOR'd config file that could easily be changed to your own malware server and HiJack LoJack. Come 2018, it's pointed out that black hats are exploiting this.
Two things come to mind.. Why so long between vulnerability and detection? And how can we be sure fancy bear isn't just a drop bear in drag. And this shows there are.. problems with UEFI
Two things come to mind.. Why so long between vulnerability and detection? And how can we be sure fancy bear isn't just a drop bear in drag. And this shows there are.. problems with UEFI
If I were really paranoid, I would suspect that this has been in the wild since maybe 2010 but only used on highly targeted, high value targets. From the description, there's no telling how long it's been out there and there's no real fix except as the article mentioned.
If I were really paranoid, I would suspect that this has been in the wild since maybe 2010 but only used on highly targeted, high value targets. From the description, there's no telling how long it's been out there and there's no real fix except as the article mentioned.
Hey, this is IT security. If you're not paranoid, you're a target! But I think there are several aspects to the story.
UEFI security, or lack thereof. That allowed LoJack to do things arguably it shouldn't have done. But the challenge with security is being able to trust it.
The threat escaped into the wild in 2009 at one of the big 50SoG conventions. I don't know when LoJack was released, but given it's role, suspect people would have been looking at how that worked as well. Again the challenge with security is being able to trust it. Which sometimes means being asked to hand over source code to TLAs or FLAs for certification. Then assuming the have the resources to identify vulnerabilities. Oh, and paranoia.. And not exploit them. Otherwise we're left to independent security researchers finding the problems and publicising them. But black hats would be doing that as well for exploitation.
Then there's the political angle. Kremlin hackers. Really? Or just HVTs. Infection route seems to have been simple spearfishing. We hear about high profile incidents, but not all, so we don't know how widely the net has been cast. Hackers would go after targets for profile/publicity as well as financial gain.. Then there's the state actors. I really doubt it's just the Russians doing this. What we could probably do with is more state level intervention to lean on software developers so they prioritise security. Again a trust issue. There can also be other attribution problems, ie the current 9/11 hack. That's been described by one victim as 'cyber terrorism', when it's clear from the demands that it's simple cyber extortion*.
I guess the good news from watching the presentation is discovering this-
https://github.com/chipsec/chipsec?language=en_US
Tools to peek into your chips. Less good news is if you discover you're infected, the fix is to try and reflash, with assosciated risk of brickage. I like the idea of having a 'secure' backup image on mobos to reflash from, but other parts of the rootkit would need to be removed first to avoid reinfection.
*More bad news. More grist for the truthers.
That expense is not the issue. The real issue in large enterprises is the same one that makes them like things such as Intel's AMT -- they want the ability to engage in system updates (including BIOS) without requiring someone to be physically at the machine in question. The savings in terms of labor costs with that are substantial.
they want the ability to engage in system updates (including BIOS) without requiring someone to be physically at the machine in question.
So these machines can have the write-enable jumper installed all the time, if they prize convenience over security. No sense in having the rest of us have to have that insecure option chosen for us because some outfits want it that way!
As Updraft says those who want to balance convenience against security can install it with the update enabled. At least it would be a conscious trade-off for them to make. I suspect there is an economic incentive - the ability to make updates without having to have staff at a higher pay-grade than click and go. Put something on the motherboard and you have to pay people able to open the box, find the switch and eventually put the whole thing back together again without disturbing anything and without leaving the switch enabled.
Or how about go back to erasable ROMs that had to be erased with a UV light before being put into a ROM writing device to reprogram? Then put the ROM back in the computer.
Ok, probably bad idea, but it is really secure. I do like the idea of a switch or jumper for modern technology.
"
A jumper block, just as with resetting BIOS, is perfect for this purpose.
"
Unlike the BIOS which would normally only be updated or reset by technically competent users, drivers may well need to be routinely updated for computer illiterate users (e.g. to make the graphics card work correctly with the latest video games etc.). Having a mechanical jumper would require the user to be able to open the case and then locate and move the appropriate jumper (which would be in a different location on different motherboards).
since UEFI is highly complex, it's likely that you'll experience serious bugs during the use of your device. Therefore you need to update it.
The obvious solution would of course be to get rid of UEFI completely and get something with minimal complexity, for example something based on the OpenFirmware standard. Having much less code is the simplest way to get rid of many bugs. Then you would have so few bugs that updates aren't necessary any more, and then you can disable writing your BIOS completely.
"The obvious solution would of course be to get rid of UEFI completely"
As a field "engineer", (not in Oregon I hasten to add!), I see mainly broken desktops, server and laptops. Apart from the odd mis-configured system that to boots to the UEFI shell, I've never had to deal with anything other than the BIOS emulator in the UEFI. I regularly replace and configure motherboard and in my experience, nothing has changed at the user or technician level interface since BIOS was a thing.
I've looked at the UEFI shell and played with it a bit. I can even do "useful" things with it, but have never, ever had to use that knowledge in anger. What is UEFI for and why does it even exist?
As I understand it, booting from BIOS in 2018 requires all sorts of horrible hacks to get it to work with modern hardware - it's early 1980s technology after all. Just because it's familiar and these hacks exist doesn't mean that continuing to use them is necessarily a good thing.
The firmware only needs to get a few things started - keyboard, disk and graphics card (and not even that if its headless) and possibly network card if its PXE boot (or whatever its called today). The rest can be done by the OS. That is one of the main reasons for an OS after all - hardware control.
How do you believe you can boot an OS if the firmware can't read the storage where it's stored? You have many different kinds of storage today, and new ones are added. You may have USB, SD, xATA, NVMe, etc. Many hardware parameters may need to be set before the OS is started. My motherboard has a lots of settings to tune the CPU, memory, etc. and the firmware needs to recognize a lot of devices and configure them, depending on what's installed on a motherboard. Some of them may be not accessible by the OS (i.e. an IPMI subsystem).
"What is UEFI for and why does it even exist?"
Well booting modern PCs is hard, as there was always a strong push for compatibility in areas where it was questionable. One example is the support for emulating AT-keyboards when you only have an USB keyboard. (that's used for running Windows, which took quite a while to support USB, to work with USB keyboards) For that you have things like "Service Mode" which contains highly privilidged code running on your CPU.
However today we can get rid of most of that stuff. Operating systems today either use BIOS functions or they have direct hardware drivers for current hardware. So in theory we could get rid of "Service Mode" and other bugs like it.
However allow me to introduce a conspiracy theory. Imagine you work for a secret service. You'll look around you and you notice something terrible happening. More and more people are encrypting their communications, less and less of that code comes from companies you can controll. It's simply not feasible to add a weak cypher to a crypto suite without people getting suspicious.
However you have one chance. If there are bugs in the implementations, you can find and use them. Now the crypto-primitives (AES, hashes, etc) themselves are rather secure. They have defined inputs and outputs, and if 2 implementations deviate at least one of them is simply broken. What is left is the protocolls. So what you do now is to support bugs. The easiest way to do so is to make the protocolls so complex, that nobody can implement them without making major bugs. Introduce certifications so people are afraid of cleaning up code. The more complex your protocol will be the fewer implementations you will have and the more bugs those implementations will have. If I worked at a secret service, I would love HTTP/2 as it greatly increases complexity at both the server and the client. I would love the modern web with it's numerous redundant features. UEFI would seem heaven sent, as it means that BIOS chips will be really large, and end user neither have any chance of knowing if it'll be bugged nor be able to use their own, minimalistic and safe, versions. It'll be like in the "good old days" where you could just tell Microsoft to include your key into the system.
"since UEFI is highly complex, it's likely that you'll experience serious bugs during the use of your device. Therefore you need to update it."
I have never needed to, or actually, updated the firmware on my UEFI machines.
I'm with you on it being flaky, though. Just last night I lost a few hours because UEFI began to refuse to boot to my hard drive after I booted it from a USB stick.
I ABSOLUTELY second this!! Should be a requirement on new pc's - and guess what? Have a backup automatically made of the BIOS at the time of update - suddenly got a rootkit on your pc? Simply reboot, hold down another button, or even go into the BIOS itself, and no more rootkit.
Although that wouldn't solve the problem of a sleeper rootkit that might get backed up without you realising it was there.
It would however make sense if PCs were supplied with a fall-back BIOS in non-rewritable ROM that could be copied back, if possible without CPU intervention, if the flash version is found to be compromised.
"It would however make sense if PCs were supplied with a fall-back BIOS in non-rewritable ROM that could be copied back, if possible without CPU intervention, if the flash version is found to be compromised."
I believe my old, but rather trusty motherboard, has exactly this feature.So it can be done. But it's a "proper" BIOS; not UEFI.
"It would however make sense if PCs were supplied with a fall-back BIOS in non-rewritable ROM that could be copied back, if possible without CPU intervention, if the flash version is found to be compromised."
There are boards which have that. IIRC, HP do it. Not sure if the "backup BIOS" is in ROM though. One of my desktops has two copies of the BIOS, the newest version boots and an update (ie newer than both copies) replaces the oldest one and becomes the boot BIOS.
"Have a backup automatically made of the BIOS at the time of update"
Not bad. Even simpler, a mirror of the factory default BIOS, with a built-in ability to EASILY reset to factory default at the hardware level, before the BIOS/UEFI setup screen shows up, like for an embedded device [hold this button down for 'n' seconds while powering up - like that - could also be a jumper].
That built-in ability, of course, would have to be in a truly read-only memory area with no possibility of 'updating' or circumventing it, and ALWAYS run on startup to check for factory reset.
Also, from the article: "not opening emailed applications as a system administrator helps a lot"
i.e. "Practice Safe Surfing". And no e-mail views/previews with HTML enabled nor attached/embedded thingies previewed.
This post has been deleted by its author
Of course, a lurking rootkit installer could sit in the background and watch for a valid attempt to update flash memory, and then add its payload before you've had time to switch off writes again.
As you said 'undefined value of safe' - 'safer' as it could protect against hit-and-run attacks but there could still be ways around it.
"Of course, a lurking rootkit installer could sit in the background and watch for a valid attempt to update flash memory, and then add its payload before you've had time to switch off writes again."
Yet another reason for never doing firmware updates from within Windows. I always boot a pendrive into FreeDOS for BIOS/UEFI updates or hardware diagnostics. I don't know enough about the internals of Windows to know for sure if the software is talking direct to the hardware or if there's a chance it's going via a potentially buggy Windows API, possibly multiple layers.
Surely in order to update the BIOS you have to remove the EPROM, peel the tape off the quartz window, then put it under a UV light for 5 minutes or so to erase it, before burning the new code off-board on a programmer?
At least that's how it was done the last time I updated a BIOS.
@Cynic_999
The terms BIOS vs UEFI [which really _IS_ a type of 'BIOS' ok?]
yeah ok, nit-picking terms. whatever. not laughing. too many people actually DO this sort of thing. OK maybe THAT is the joke, on people who DO this sort of thing IRL and not just as a joke...
(unless for some reason I misinterpreted what you meant, I haven't finished my coffee yet)
@Cynic_999, I recall "fondly" doing just that with a shitload of Psion II mempaks.
What is needed is control of the physical WE pin on the flash. Just bring it out to a header and leave the link off and pull the bugger low with a 4k7 if the 0.005p of fitting a pin-link is prohibitive. Those two pins in between the speaker header which are always there but never used would do nicely with the advantage that on most mobos, there's already a logic 1 source available at that location for the positive side of the speaker. Pull speaker connector, bung pin-link on, boot to FreeDOS, Bob's your shouty uncle.
"Also, not opening emailed applications as a system administrator helps a lot"
The rest of the toolkit* has an extensive collection of privilege escalation tools revealed in previous analysis by other AV and security players. What user ID will you open an infected email is irrelevant. If you are an idiot enough to open it and click on the attached spear-fish payload or spear-fish link you are as good as dead even if you have disabled any and every right you can think of for this luser.
(*)if the discovered functionality is what it is, I struggle to see the point of having something that cannot defeat secure boot
... on Windows a lot of business software requires you to run it as root. After all it needs to do things like access printers directly (for example for POS systems).
Windows, by default, does not display file extensions, making it extremely hard for an untrained person to spot a .doc.exe file. Since running applications with different permissions on a single login is hard, and partially useless, few people set that up.
The obvious practical solution is of course to use mainboards with their UEFI on a socketed DIP-chip and get a professional flash chip writer (about 200 Euros) and just regularly replace your flash chips with the newest version. Additionally you can just make a write enable yourself, by soldering the write enable pin to whatever level disables writing. One could even build little boards that go in between the mainboard and the chip to do that.
"Yes, the only thing that I find more baffling ... is that Microsoft still hasn't changed that default"
Not baffling at all. They don't care. The JJ Carters of this world will happily impose this mess on 4000 users and brag about it so with a plentiful supply of administrators like that why should they care?
I'd be more concerned about a sysadmin who had not installed "sh**t scanners" and quarantine systems on the inbound email servers, now that's bad systems management. Everyone makes mistakes, they shouldn't but we're human, so to remove the temptation you remove the chance of accidentally running something stupid from an email by quarantining it at point of entry and notifying the recipient. Heck, you can even get services that will rewrite or remove URLs from emails on the fly before delivery.
There's no excuse in this day an age for anyone in IT in a business to be in the position to be able to run executables or see URLs in emails!
"There's no excuse in this day an age for anyone in IT in a business to be in the position to be able to run executables or see URLs in emails!"
Try telling that to the Sales and Marketing departments!!!
We ARE an IT company and you'd not believe the shit they send out, even internally! Exactly the sort of stuff we should be wary of. Having said that, we recently a security advisory warning users about phishing emails. It was a pretty coloured image file you had to click on to get the rest of the information about what not to do which basically told us not do what we just had to do to get the information on what not to do.
I did consider that it might be a double bluff to see if people would click it, but then considered the previous missives from our "security department" and discounted that level of intelligence.
how about this one: IT recruiters requesting your resume in WORD DOC FORMAT
(pause for effect)
yeah no security problems THERE.
I wonder how many IT pros would say "here it is in plain text" or "I have a PDF, how about that?" knowing that perhaps sending MS Word format documents as e-mail attachments is some kind of "test" to see how security-savvy you are?
"And why would a recruiter want your CV in an editable format?"
Very few placement agencies will hand your CV out directly. They want all of the CVs they send out to be in a standard format, and typically want to strip your contact information out, to prevent companies from reaching out to you directly (and thus cutting them out of their commission).
There's no excuse in this day an age for anyone in IT in a business to be in the position to be able to run executables or see URLs in emails!
If you can see a bit.ly or similar URL masker in your email, you're doing it wrong. Or your security department is doing it wrong.
Spearfishing relies on persuading users to click on things they shouldn't. Persuading users not to blindy click is a much greater challenge. Especially when they're SES, GS10+ or equivalents that hackers may be looking to spear.
I never click on bit.ly etc URL's. There is no telling where you will end up.
Just clicking on one in the UK could see you end up in Jail and on the sex offenders register for life as the innocent bit.ly URL could take you to a child PRON site and just viewing it is a criminal offense.
Anyone I know who sends me one of these gets a curt but polite reply asking for the real URL.
It is up to you to keep your system safe. Don't take risks.
If you can resolve domain names like bit.ly or get HTTP requests to it through the transparent proxy, your security department is doing it wrong.
URL maskers (just like file-extension hiding) are the bane of security. They should all be blocked outright.
What absolutely staggers me is how popular they are amongst regular common folk. WHY do people feel the need to go and take an extra, manual step to shorten their URLs? Seriously, outside of character-limited places like Twitter (which I don't use, anyway) there's no need. It defies my belief that regular people are inherently lazy.
> There's no excuse in this day an age for anyone in IT in a business to be in the position to be able to run executables or see URLs in emails!
One can always choose an email client that _doesn't_ automatically run executables or load URLs when the email is opened, or even without it being opened, or even one that does not allow running or loading when these are clicked, and defaults to using plain text rather than html.
But then a) it wouldn't be Microsoft, b) it wouldn't be pretty.
"There's no excuse in this day an age for anyone in IT in a business to be in the position to be able to run executables or see URLs in emails!"
There's no excuse in this day and age to have to go to the lengths you describe but marketing departments the world over employ numpties than make it necessary.
Any system administrator who does this should be fired for gross negligence.
How about
Any system administrator who does this other than in a disposable VM on a firewalled machine in the basement and inside a faraday caged room labelled 'here be dragons' should be fired for gross negligence.
That seems better... :)
That would work.
My approach is a bit simpler, though -- if I'm sent an attachment that I wasn't expecting to get, then I don't open it until I've contacted the sender (through a means other than email, usually by phone) to confirm that they intended to send it. If the email is from someone I don't know well enough to contact out-of-band, then it just doesn't get opened.
The link to the Frederic Vachon presentation is the german-dubbed one. It all sounds like a killer joke to me.
If you go to the official link https://media.ccc.de/v/35c3-9561-first_sednit_uefi_rootkit_unveiled , you can choose between audio versions and listen to the original audio on CCC's video player .
I never quite understood why people link to externally hosted versions of CCC talks. I mean they are only on services like "YouTube" to promote decentralization. However the popularity could easily overload their servers if a significant share of views would go to those. In contrast, the media.ccc.de servers are load balanced so they can easily handle even huge loads.
Is why the articles are not mentioning the name of the company that makes the LoJack software - Absolute Software ?
What I want to know is which vendor ships with secure boot disabled in this day and age and which government has it disabled on PCs running Windows.
The last time I have come across a laptop which came with secure boot disabled from factory was in October 2012. Everything after that had it enabled.
Dunno, it's probably me missing something, but I do not see the point of having this functionality in a rootkit except for "tick the box" purposes. Who are the potential targets?
> Is why the articles are not mentioning the name of the company that makes the LoJack software - Absolute Software ?
Or that if LoJack finds its application missing it download a fresh copy rpcnetp.exe from a generic html server. So basically the GRU hijacked the NSAs rootkit :]
firmware developers are the worst type of software developers when we come to speak about application security.
Also somebody with the knowledge please enlighten us on why drivers should be delegated to firmware instead of OS ? Old BIOS worked just fine for decades with only a minimal disk driver which was overwritten by OS anyway.
And yes, I agree with all of us here who say OS should not be allowed to fiddle with firmware. A hardware switch will be a problem when you need to update a fleet of hundreds/thousands of PC but a separate bootable environment or something that can be plugged into PXE could be a safer alternative that worth considering.
A hardware switch will be a problem when you need to update a fleet of hundreds/thousands of PC but a separate bootable environment or something that can be plugged into PXE could be a safer alternative that worth considering.
Then, when they buy and deploy PCs, companies can feel free to set the firmware write switch to "open slather" for their convenience whereas for everyone else it can remain in the "name's not down, you're not coming in" position.
"Also somebody with the knowledge please enlighten us on why drivers should be delegated to firmware instead of OS ?"
What happens when (not if) your OS doesn't support your hardware? The idea is to make the whole "device support" bit OS-agnostic and not dependent on coders' whims. What would you propose instead that doesn't depend on coders' whims?
If the OS doesn't support the hardware, what's the point of installing it in the first place ? As for coders whims, your proposition is to replace OS coders by firmware coders which is like shoveling the sh%&^t forward. All this driver mess is because hardware manufacturers jealously want to keep their products specifications secret and instead of allowing decent, professional software engineers to code the drivers, they come up with their own half-baked and insecure solutions. Like BIOS, UEFI is a valid proof of that.
You should read a little more. Architecture-independent drivers was a stated goal of EFI. Why would it be terrible to not be held hostage by the OS? Plus recall, without an advanced system like EFI, native support for large (>4TB) drives wouldn't be possible without bodges. Same for the M.2 spec being encouraged for SSD's.
Thanks for the link. This is not an area that I'm expert in, obviously, but I don't see in the Wikipedia article where it says that the goal of UEFI is to replace OS drivers. It looks like it's intended to make the BIOS more flexible.
"Why would it be terrible to not be held hostage by the OS? "
Why do you think of it as "being held hostage", when a major part of the purpose of the OS is provide interfaces to using hardware? Is it better to be "held hostage" by UEFI instead? Why?
Here's why it's a terrible idea: how do you install new drivers to support new hardware? How do you provide specialty drivers for established hardware? How do you use an alternative driver if the stock one doesn't work for your needs? How do you replace standard drivers with ones you wrote yourself?
Drivers belong in the OS, not in BIOS, unless perhaps you're talking about building an "appliance" computer that isn't intended to be general purpose.
I'm talking about the baseline: the drivers to support the motherboard itself, which isn't guaranteed in the OS (I've had to dump laptops whose chipset support got dropped). Add-on hardware of course has to be done separately, and there's still the issue of new standards which BIOS can't support due to architectural limitations. EFI of some form is rapidly becoming a necessity to deal with new hardware.
"What happens when (not if) your OS doesn't support your hardware?"
You switch on your computer. Your OS is sitting on your disk. Only your OS has drivers to read from disk. How do you get any of it into memory so it can run to read the disk to load itself into memory so it can run?
I know. Rows of switches on the front panel so we can toggle a first stage boot loader into memory, just like the old days.
just imagine what intelligence and law enforcement agencies of the five eyes buddies with unfettered access to UEFI encryption keys (say it aint so) would be able to achieve. A nightmare for those on US naughty list and maybe (by "honest mistake") US allies too.
just imagine what intelligence and law enforcement agencies of the five eyes buddies with unfettered access to UEFI encryption keys (say it aint so) would be able to achieve.
The extensive and continuing failure in the wars against drugs, organised crime, and terrorism would suggest that if they have that access and use it, it hasn't proved very effective.
I was looking for the Linux angle on this story, but this comment does not supply it.
To install Linux I have to disable UEFI "security". Am I more vulnerable to this malware because I have done that, or less because I never run Microsoft?
Please excuse my naivety. It would be very useful if someone could give a link to an explanation of what one is supposed to do about UEFI when installing Linux, either single- or dual-boot. Thanks.
Some Linux distros are signed and can be used with secure boot enabled, but I think there can be issues with some propitiatory video drivers, etc, that break the trust-chain in such cases. In any case "secure boot" is only good at stopping some cases of root kits, and would not stop anyone capable of using Microcsoft's keys, for example, or of exploiting the generally piss-poor state of UEFI (or BIOS) firmware security.
If you are worried about security in general then a good starting place is the guidance at NCSC which cover many OS, not just Windows as one might expect, and including Ubuntu Linux:
https://www.ncsc.gov.uk/guidance/eud-security-guidance-ubuntu-1604-lts
Any security system that relies on a user never making a mistake is fundamentally flawed; users will make mistakes. Thus the UEFI security model was written by complete idiots who are relying on user perfection. Everyone (and I am including myself in this) will make mistakes when it comes to security for numerous reasons, even the most skilled and aware. It justs takes the right person to make the mistake and security just got flushed.
"Any security system is fundamentally flawed, period." Two words: Murphy's Law. SOMEONE's going to screw up just enough to mess up everything, and humans aren't perfect. Also, no matter how hard you try to keep things from breaking, you can only set the bar so high at the start while it constantly lowers over time (the siege problem).
" eggheads" -- Ah, you know you are reading an article by an American when you see this term as it is totally anti-intellectual.
The English are intelligent e.g. Alan Turing, Charles Babbage, Ada Byron Lovelace etc.. etc...
The French are intellectual e.g. Blaise Pascal etc...
Americans are fat , ignorant and lazy hence terms like egghead. How is tossing around the term 'eggheads' working out for Americans while they are being anally raped (hacked ) by Russia , China and South America ?
How needlessly pedantic of you. If a word is enough to set you off I'd probably not want to be in the same room should someone errornously type out an "armor" or a "color!"
"Egghead" has lost most of its negative connotation and is nearly equivalent in sting to "boffin;" both funny words but you'd likely not say either in front of a neuroscientist. It just so happens that the atmosphere here at El Reg is fairly relaxed. (Extra credit: Someone find a post written by a non-American where the word "egghead" is used instead of "boffin" and I will mail you an egg roll)
The US was and is home to many, many brilliant scientists both native (John Nash Jr., Donald Knuth, Oppenheimer, Grace Hopper, Carl Sagan, Benjamin Franklin, George Washington Carver, Richard Feynmann...) and foreign (Nikola Tesla, Albert Einstein, Isaac Asimov, von Newmann, Enrico Fermi...) and it would do them even more of a disservice compared to simple fun-poking naming by striking off the whole place with a broad generalization. Even beyond that, science is a worldwide, collaborative effort, one that transcends nation, ethnicity, creed, and whatever else.
You want to mock and stereotype the USA and its commoners, go ahead—but leave the scientists out of it.
>> How needlessly pedantic of you. If a word is enough to set you off I'd probably not want to be in the same room should someone errornously type out an "armor" or a "color!"
Would it be needlessly pedantic of me to point our that in this context, the exclamation mark should be placed outside the quotation marks rather than inside?
Would it be needlessly pedantic of me to point our that in this context, the exclamation mark should be placed outside the quotation marks rather than inside?
No, it would be incorrect to point this our.
Since it was "color" (American spelling) that went inside the quotation marks, it would be logical to assume that the writer is using American English. That being the case, the exclamation point goes inside too, as is correct in the US.
""Egghead" has lost most of its negative connotation and is nearly equivalent in sting to "boffin;" both funny words but you'd likely not say either in front of a neuroscientist."
A few lifetimes ago, I worked in a neuroscience lab, and it wasn't unheard of that the scientists would refer to other scientists (in the abstract) as "eggheads". So, while I agree with your comment, I wouldn't personally be shy about using the term in front of them.
As you say, it's not an insult. It's affectionate slang.
My comprehension is that "eggheads" refers to those who work purely theoretically, whereas "boffins" are those who combine the theory with the practical tinkering necessary to produce a working version.
However there is some blurring of this distinction, as I would consider Trevor Bayliss to be a Boffin, but I would also put Barnes Wallis in the same category, even though strictly he was an Egghead.
Oh, and I don't consider either term to be pejorative or derogatory.
Ah, the anti-American trolls. So sure of their own superiority.
So, Mr. troll, as a "fat, lazy American", I have a question for you; how many marathons did YOU run last year? I'm pushing sixty and ran two. I'm in the gym three days of the week and distance running another three. I plan on adding another marathon to my schedule this year making a total of three.
As for "ignorant", I'll just consider the source of the accusation (Yeah, that would be you, big guy! Great guess! Have a cookie!).
Just like every other country in the world, America has its problems. We're working to solve those. We will be successful.
So, you have fun relaxing in your coffee shop, sipping your espresso, smoking your cigarettes, and bitching about the stupid, lazy, Americans with other trolls just like yourself. The rest of us (Americans, British, French, etc. alike) will continue on with our lives while you continue bleating.
You're pathetic. Have a great day!
I hate to say this, but whoever wrote that crap software with the race condition should be tarred and feathered and put on public display in the Stocks --- it is SIMPLE to have something that could NEVER be hacked in this way. Instead of a routine scanning and perhaps allowing a flash, have the routine run as a hook AT THE TIME of the flash, from the rom itself (below the level of even the firmware - in ROM, not FLASH memory), so no matter how many times the flash attempt is made, it will always fail.
Have a physical switch or jumper like they used to do in the 'good ol' days', have a backup automatically made at the time of flash, etc.
But then, no one seems to be capable of, well, y'know, actually designing GOOD code anymore. OHHHH, but you have to be a little 'gentle' on 'modern' programmers - after all, they are used to 'java', don't'y'know - but then, IMHO, system level software needs to be written in such a way that these things simply do not even have a chance of happening. And PLEASE don't talk about 'well, how you gonna see every bug in your code - you would have to do QA until past eternity', especially when good programming simply AVOIDS these things in the FIRST place. See mwhat I said about having the check happen at the time of the flash, in rom, instead of some stupid driver that can stop or fail, for example.
Oh, and yes, I have programmed for many levels, and no matter what level I program for, even if I have only a very limited understanding of the machine itself, I have never had trouble creating fast, compact, reusable, extensible, secure code that is mostly bug free, but written in such a way that bugs can be found and fixed in less than 5 seconds TOPS! It's a simple matter of thinking about what you're doing. And, yes, I have had 'younger' programmers call me 'old school', only to come back to me LITERALLY crying because their pet project, beautifully-looking, super object-oriented library-using brand-spanking new code ends up failing in a way that they simply do not have the mental wherewithal to even conceptualize, let alone understand, and I would fix their code in less tghan 5 seconds flat. Oh, and yes, you can write OO code without all them expensive tools which create more problems than they could ever fix, while slopslowing things down by thousands of orders of magnitude, while creating backdoors and stack oveflows.
Am I sounding 'old-school'? I am not trying to sound arrogant, like anyone, programmers, singers, musicians, writers, etc. (and yes, I am all of those), I never stop learning, and I always like to see and learn new things. But at the end of the day, there's basic skill, and to have something like this happen is a total mess for Intel. Yes, this has been around far longer than 2014, and yes, there are many more, even worse cracks out there, I am sure of it. And yes, this could be purposeful even. I bet this was but in place as a Government backdoor, as an example.
Anyway, peace and Happy New Year everyone, and just try to write simple, well-written code!
I'm a bit unconvinced about the 5 second fixes, especially on someone elses (and hence very unfamiliar to you) code.
.. If its in a non trivial application it will take more than 5 seconds to load it all in development tool of choice and open the appropriate files that need investigating.
Many (not all, some need major rewrites) bug fixes are "quick" in terms of amount of code change needed, but tracking the bug down is typically a lot slower when you are looking at code you are unfamiliar with (even worse when none of the people who originally wrote it are around to talk to!).
"Have a physical switch or jumper like they used to do in the 'good ol' days', have a backup automatically made at the time of flash, etc."
Remember, these machines can be buried or remote, meaning physical switches are not an option since that will mean expensive physical trips.
Of course they are an option. You simply set the 'write-protect switch' on remote machines to 'write-enable' and leave it there, leaving you in exactly the situation you are now. Having a manual switch does not prevent you from implementing additional software-based methods to inhibit firmware writing.
What is less than clever is not having the option of using a physical write-enable switch, which would be a major security gain. One could almost think there is a government-inspired reason why physical write-enable switches are not available, but that gets into tinfoil hat territory.
"Of course they are an option."
No, they're not. Once they're there, someone's going to mandate its use, which presents a problem when it turns out you locked in a vulnerable firmware, only it turns out it's SO difficult to service physically that it'd be far cheaper to just pay any fines.
"Remember, these machines can be buried or remote, meaning physical switches are not an option since that will mean expensive physical trips."
Security costs money. The less you spend, the less secure your system. Maybe those expensive physical trips are expensive, but are they more expensive than the potential losses (and/or fines)? Security professional and beancounters will probably come to different conclusions.
"
Remember, these machines can be buried or remote, meaning physical switches are not an option since that will mean expensive physical trips.
"
You can install relays instead of physical switches that are controlled by a separate hardware box that can be operated remotely. I once installed a remote landline operated mains switch on a server that was prone to crashing that allowed me to do a remote "switch off and back on" just by dialling a number and sending a sequence of characters to the remote modem.
"while slopslowing things down by thousands of orders of magnitude,"
I remember when I was first shown the "new" BIOS that was no longer written in assembly language. You could see the screen updates happen in the BIOS config screens. Of course, assembly language programmers cost more than JAVA-like programmers and I suspect that was one of the prime motivators behind the change.
“Sednit group, also known as APT28, Fancy Bear, Strontium, and Sofacy .. is a state-sponsored hacking group believed to be .. associated with a number of high profile attacks, including the DNC hack just before the U.S. 2016 presidential election” ref”
The DNC wasn't hacked, according to the time-stamps, the files were copied locally and then uploaded elsewhere to a website, as such it would have to be an inside job. you would think the GRU would be more careful in disguising the source of the Russian malware :]
And you think that people who went out of their way to edit the time stamps then carefully opened each document they purloined in an old version of Word (a special old version too, one that retained URL errors using the installed character set) using a Cyrillic character set and saved it without changing anything ? And that this action had the effect of embedding these cyrillic character error messages where they could be seen, why, almost as if that is why they did it ?
So these professional hackers who were so careful, just happened to make a very specific mistake to leave and "unmistakable" trail leading to their undoubted origin, Russia ?
Looks awfully like a piece of deliberate false flag attribution to me. And Guccifer2, claiming to release DNC documents that were really actually from the Podesta eMail hack, and releasing only non-damaging info (an old oppo research document on Trump - really !). Why, one would really start to wonder if this was all just part of a disinformation campaign to disguise the actual exfiltration by insiders.
And that WOULD be funny.
Is UEFI specific to x86 and/or x86-64 systems? That's where it came from initially, right?
What's the impact on the world of MIPS, ARM, and indeed any other non-x86 architecture chip+system?
Is LibReboot (sorry, meant LibreBoot - sometimes case-sensitivity is important) or equivalent potentially relevant in this picture?
Great, so what I'm hearing is that I should also be disabling UEFI? Even though it really can provide some useful support features, ie for suspend/resume support etc? Great.
As usual, anyone outside the 80% is shafted. (On the bright side, 99% of the exploits expect a windows OS, so there's that.)
I think it will be a sign of what is going on behind closed doors, if Bloomberg do not report on this. As if the discovery of this was at a similar time the pretend article on Chinese motherboard hacking was released... I'd say someone somewhere was trying to divert public eyes. Possibly Only investors or companies, no special operations.
Because this is the real hacking, while the Bloomberg seems to be entirely fictional. The originators of this hack, the sellers of hardware, and eventually states, would have wanted more fakery than fact amongst the public.
Microsoft instructs OEM's how to create a boot for their Windows o/s UEFI lets them create a buttfuck that will disable your computer when the primary drive's boot information gets overwritten.
All the (PBR ) Push button resets and other Windows emergency repair shit will not put your bootable PC/drive together again. You will have to completely reinstall everything.
As the tools supplied and available on the Internet will NOT allow you to properly identify the hard drive Windows boots from while booting from an alternative location i.e CD(X:), the PBR USB or the Windows Recovery O/S still (X:). Individually you can view the correct information in various tools but none will use this info to recreate or overwrite the old boot info with the correct/correctly adjusted information - The Windows-10 EULA says "No Work-Arounds".
Years gone by I was not required to hack my BIOS to load drivers & if I could have loaded them as BIOS extensions into an isolated storage area on BIOS then I would have loved to do this, but few manufacturers allowed you to take up this option.
When the likes of Acer allowed laptops, primarily, to push some keys and change their BIOS settings from within the operating systems, it was clear that the Users was doomed. that BIOS was now hackable by whoever had the gall to do it and that there was no going back.
It is all in the name of convenience that your security & access to your computer is made more available to developers, manufacturers and hackers than to you. All you get is some shallow piece of crap you will properly forget to use correctly anyway.
Had a look around for a non-expert description of how to check if our PCs are vulnerable and if so how to protect them. UEFI discussions get to a mega level of complexity quite rapidly. I was hoping for somethjng like boot-to-bios-configure, check Secure Boot setting, switch it on, sorted. Win 7 Dell Vostro laptops. Cheers in advance!
The move to UEFI was probably driven less by shadowy state players (given the level of incompetence that seems endemic in all governments, it seems odd they can pull this of with no trail of cockups behind them) and more by a simple move to make PC maintenance cheaper. After all, if you have to start opening cases and touching bare metal, you're going to need someone with some level of expensive (and transferable) knowledge somewhere.
Far better eliminate that person, and make systems configuration something a user can do from a link.
No, the move to UEFI was paid for by M$ As an effort to get a tighter grip on the x86 platform. The smoking gun is right there- why would Ubuntu and Red Hat be forced to pay M$ to sign GRUB (and the kernels, and the kernel modules) so it can boot? Why can’t Ubuntu or Red Hat generate their own keys, put it on the DVD image, and why can’t the user just instruct UEFI to install those keys? Why must it’s be M$’ keys?
Not if it uses intel flash memory anyway- a possibility even on AMD platforms. I recently built an AMD ThreadRipper workstation and the chosen motherboard (Asrock X399 Taichi) had Intel flash memory iirc. It also has Intel Wi-Fi, Intel Bluetooth and Intel LAN much to my annoyance.
On one computer I worked on (a long time ago, in a galaxy far far away), the "load" sequence put a set of about 10 32 bit words into memory, and included the device number of the "boot device" (it could be cards, tape, paper tape, or disk). The next operation was to execute this sequence to read in the first record from the designated media and continue the process. It was the responsibility of the provider of the media to correctly do the rest of the job. The BIOS we have today has gotten a bit far from its original task (to get an operating system in place) and has provided all sorts of hooks, and other grunge to make it "easy" for normal humans to do such a simple task.
The biggest problem is that the BIOS/UFEI stuff is masked and hidden from us "mere mortals" that have to get a job done. Perhaps if it were open source and examined by lots of eyes/minds it wouldn't so fragile.
One of these days motherboard vendors will listen, but I'm not holding my breath.....
Seriously, the idea of updating the boot sequence of a computer that easily should have died out some time in the mid 80s.
We need a more secure alternative to UEFI, and we need it now. The idea that an OS can blithely write to non-volatile areas without special permissions should be verboten.
I'd be in favour of a hardware switch that you have to hold down to change a single byte of the BIOS, personally. After that, the OS and every other program should see that area of memory as read only. No more storing Windows keys in there or any other nonsense like that. The boot sequence is too important to be fiddled with.
Everyone's for a physical switch until they're the ones who have to go to the middle of nowhere to throw that same physical switch for the machine that's buried under all sorts of crap that can't run while you're in it. IOW, everything's all fine and dandy until real life intrudes.