Contributed by marco on from the NVIDIA-ethernet-driving dept.
They don't provide documentation or even have a list of names for the chips, but will happily agree to let various parties distribute a driver kludged around a binary blob.
Suffice to say, we have have not taken this approach.
Snapshots starting 5th Feb for i386 and amd64 have the driver (nfe) included.
What we would really like now, is some feedback from a wide range of nforce based systems. Send a dmesg and a mention of whether you have any issues to damien (damien@openbsd.org) and me (jsg@openbsd.org).
(Comments are closed)
By Anonymous Coward (134.58.253.130) on
"The nfe driver supports PCI Ethernet adapters based on NVIDIA's nForce Media and Communications Processors (MCP)."
So I suppose all nForce-based motherboards have one of these onboard. Is this correct?
Comments
By jsg (210.15.216.215) on
By Brad (216.138.195.228) brad at comstyle dot com on
By Anonymous Coward (208.252.48.163) on
Comments
By jsg (210.15.216.215) on
Comments
By Anonymous Coward (69.70.207.240) on
You guys never fail to amaze me... Awesome work dudes!
By GeekGod (216.135.89.5) geekgod@geekgod.com on http://www.pfsense.com
Comments
By jsg (210.15.216.215) on
"Plus, users who demand the most from their PC can also use the optional NVIDIA ActiveArmor Secure Networking Engine (SNE), a hardware processor that accelerates firewall processing and is available in some versions of NVIDIA nForce™ MCPs."
This "accelerates" is most likely referring to the checksum and segment offloading the hardware supports. I don't really think this classifies as a "hardware firewall".
By Marco Peereboom (67.64.89.177) marco@peereboom.us on http://www.peereboom.us
By Anonymous Coward (202.45.99.224) on
Comments
By Nate (65.94.58.104) on
Comments
By Anonymous Coward (202.45.99.224) on
Firmware and BIOS based rootkits could get installed on an otherwise trustworthy system after you've bought it.
After compromising an OpenBSD installation an attacker could install a rootkit that would survive a hard drive reformatting.
Comments
By Anonymous Coward (213.84.84.111) on
Comments
By Anonymous Coward (202.45.99.224) on
Comments
By Anonymous Coward (202.45.99.224) on
Comments
By Roman (169.200.215.16) on
Comments
By Anonymous Coward (202.45.99.224) on
Why don't you educate yourself before telling others to do so "Yet, an insider attacker could flash their laptop before they leave a company and then use the rootkit, which would survive reinstallation of the operating system. The insider could then gain access to the corporate network at a later time." (http://www.securityfocus.com/news/11372)
And here is a presentation on the issue: http://www.ngssoftware.com/jh_bhf2006.pdf
Clearly there is a role for operating system defenses to play. This security problem is not going away.
Comments
By Anonymous Coward (212.254.169.67) on
otherwise, if you have evil intentions and physical access the game is already over. all you need is a hammer or a floppy or a dead mouse.
it's another blatant case of vendors coming out with a silly, pointless technology and then security companies making a rucus a few years later.
as if no one saw the potential for this, and a 36-slide presentation is a demonstration, right.
THE END IS NIGH! REPENT!
Comments
By Anonymous Coward (202.45.99.224) on
You do not need any "internet auto-update bios flashing thingies" like what is available for windows. An attacker has the capability to write their own code that updates the BIOS from within OpenBSD, duh. How about attempting to be constructive.
OpenBSD already has the ability to prevent root from permanently changing contents of hard disks, a feature to prevent modifying of device firmware would imho be very useful. That way if you were running your system in the right securelevel you could be sure that the attacker has not implanted a backdoor inside device firmware.
Comments
By Anonymous Coward (82.197.192.49) on
What you are asking the kernel to do is anologous to asking userland to protect against an evil kernel. That's not gonna work.
By Anonymous Coward (212.254.169.67) on
And if you're worried about limiting the damage your disgruntled ex-employees can do, what's more important, worrying about a possible backdoor on some laptop or denying them access to your database servers?
How many companies have effective policies for this and actually carry them out? I've personally had my laptop seized from me on a Friday and still had full access to critical servers on Monday, and not in a small company.
The point is risk-management. This is a silly little issue, UNLESS you're running some kind of automatic BIOS updates, because then you don't need root, you just need to serve the file to the process.
By Anonymous Coward (202.45.99.224) on
Comments
By Roman (169.200.215.36) on
Comments
By Anonymous Coward (202.45.99.224) on
Well the problem is there are so many places malicious code could be hidden. From DVD burner firmware to the BIOS and god knows what else. And if malicious code has been placed there it could easily stop your BIOS updates from overwriting the malicious code (unless you physically take out the memory chip and flash it that way).
Though I do agree a jumper on the motherboard is a much better way to prevent flashing of the BIOS. Though im not sure what hardware enforced methods there are available for preventing flashing of devices like DVD burners and RAID cards.
Thanks for offering constructive comments.
By Shane J Pearson (202.45.125.5) on
I've seen some PC's with RO jumpers and certainly my Sun machines have them.
Honestly though why should we OpenBSD users care about this "issue". I might be concerned about Windows machines but why ask "what is OpenBSD doing about this"? They have already been doing what is needed from the start, coding with correctness in mind. If they keep on that track there is little chance a rootkit could be executed in the first place, let alone actually get write access to the system PROM.
This is really a silly issue. Wipe out the BIOS, install something nasty in it, wipe out your HDD, install something nasty in it, steal data from it... it is all addressed the same correct way in OpenBSD and in a suspect manner with many other operating systems. So why bother coming here and asking what OpenBSD is doing about this? They already have it covered with the best attitude that can cover it for systems which might be "vulnerable".
By tedu (69.12.168.114) on
Comments
By Anonymous Coward (202.45.99.224) on
By Anonymous Coward (216.62.11.163) on
Comments
By Shane J Pearson (202.45.125.5) on
Comments
By btimby (12.222.146.208) on
The best answer is that this is not the job of the OS, the OS must defend against attackers running code on your machine in the first place. Failing that, the best idea is for paranoid admins to flash systems after compromise with known good firmware from their vendors. The problem with Windows and other OSes is that they don't do a good job defending against attackers in the first place, while OpenBSD does.
Comments
By Anonymous Coward (216.62.11.163) on
By tedu (69.12.168.114) on
Comments
By Anonymous Coward (202.45.99.224) on
This issue makes it so much more difficult to clean out any nasties an attacker may have left behind after compromising your machine. It is reasonable to purchase a motherboard with read-only jumpers for the BIOS but almost no manufacturers have DVD burners, RAID cards and other system components that have read-only jumpers.
I dont want to have to chuck out a whole PC just because there was a root level compromise of the OS.
Comments
By Shane J Pearson (202.45.125.5) on
I think this problem is not all that bad as far a rootkits go.
1. Motherboard chipset boots BIOS.
2. BIOS detects and preps some hardware, then boots boot sector of chosen boot device (HDD, etc).
3. HDD boot sector boots and then boots a kernel or some sort of boot manager.
4. Kernel is booted and modern OS then mostly no longer uses BIOS calls, right?
So in effect for the rootkit in the BIOS to be executed with effect to the system OS, it needs to be executed after the system OS has come up. Right? So regardless of whether it is a good BIOS or a tainted one, an OS still would have to be compromised to get that hidden rootkit in the BIOS to be executed. In which case, if the OS could be compromised then they wouldn't need to execute the rootkit from the BIOS.
Assuming of course that modern OS' take over completely from the BIOS at some stage and never have to use BIOS calls after that? Is this the case?
Similar deal with DVD firmware. To have the rootkit executed, something needs to execute it (as in read the pertinent contents from the firmware to the system RAM and then execute it). That malicious something has to be on the system and thus that is malicious code on the target system. If that code can get there then why bother hiding a rootkit in some firmware? For next time after the OS is reloaded? It will still need the malicious code to execute the hidden code. There's no point. It's like trying hard to exploit a system which is already exploited. If the OS is reloaded and patched, then you have a system which is currently not exploitable, which has a hidden rootkit which currently can't be executed by the attacker. Pointless.
I think the real danger is with something I've been waiting for for a long while... a DoS from a virus, worm, etc where a systems BIOS, boot blocks and all are simply zeroed out. I could see that causing havoc to the Windows world.
Comments
By Brad (216.138.195.228) brad at comstyle dot com on