Slashdot Mirror

Network Cards & PCI Cards Firmware: No protection or detection of rootkits / malware, & AMD CPU issue

# Designing and implementing malicious hardware

"Hidden malicious circuits provide an attacker with a stealthy attack vector. As they occupy a layer below the entire software stack, malicious circuits can bypass traditional defensive techniques. Yet current work on trojan circuits considers only simple attacks against the hardware itself, and straightforward defenses. More complex designs that attack the software are unexplored, as are the countermeasures an attacker may take to bypass proposed defenses.

We present the design and implementation of Illinois Malicious Processors (IMPs). There is a substantial design space in malicious circuitry; we show that an attacker, rather than designing one speciïc attack, can instead design hardware to support attacks. Such flexible hardware allows powerful, general purpose attacks, while remaining surprisingly low in the amount of additional hardware. We show two such hardware designs, and implement them in a real system. Further, we show three powerful attacks using this hardware, including a login backdoor that gives an attacker complete and highlevel access to the machine. This login attack requires only 1341 additional gates: gates that can be used for other attacks as well. Malicious processors are more practical, more ïexible, and harder to detect than an initial analysis would suggest."

https://db.usenix.org/event/leet08/tech/full_papers/king/king_html/

# Attacking network cards

"I've reached my goal of writing a totally transparent firewall bypass engine for those firewalls which are PC-based: you simply overwrite the firmware in both NICs and then perform PCI-to-PCI transfers between the two cards for suitably formatted IP packets (modern NICs have IP "offload engines" in hardware and therefore can trigger on incoming and outgoing packets). The resulting "Jedi Packet Trick" (sorry, couldn't resist) fools, amongst others, CheckPoint FW-1, Linux-based Strongwall, etc. This is of course obvious as none of them check PCI-to-PCI transfers. "

https://lwn.net/Articles/284162/
http://www.links.org/?p=330

# 'Super-secret' debugger discovered in AMD CPUs
# Password-protected feature goes beyond x86

http://www.theregister.co.uk/2010/11/15/amd_secret_debugger/

# Super-secret debug capabilities of AMD processors !

http://www.woodmann.com/collaborative/knowledge/index.php/Super-secret_debug_capabilities_of_AMD_processors_!

# Hidden Debug Mode Found In AMD Processors

http://hardware.slashdot.org/story/10/11/12/047243/Hidden-Debug-Mode-Found-In-AMD-Processors

# A microcode reliability update is available that improves the reliability of systems that use Intel processors

http://support.microsoft.com/kb/936357

# Google: attacking network cards malware, PCI rootkit, PCI rootkits, rootkit firmware, etc.

Network Cards & PCI Cards Firmware: No protection or detection of rootkits / malware, & AMD CPU issue

# Designing and implementing malicious hardware

"Hidden malicious circuits provide an attacker with a stealthy attack vector. As they occupy a layer below the entire software stack, malicious circuits can bypass traditional defensive techniques. Yet current work on trojan circuits considers only simple attacks against the hardware itself, and straightforward defenses. More complex designs that attack the software are unexplored, as are the countermeasures an attacker may take to bypass proposed defenses.

We present the design and implementation of Illinois Malicious Processors (IMPs). There is a substantial design space in malicious circuitry; we show that an attacker, rather than designing one speciïc attack, can instead design hardware to support attacks. Such ïexible hardware allows powerful, general purpose attacks, while remaining surprisingly low in the amount of additional hardware. We show two such hardware designs, and implement them in a real system. Further, we show three powerful attacks using this hardware, including a login backdoor that gives an attacker complete and highlevel access to the machine. This login attack requires only 1341 additional gates: gates that can be used for other attacks as well. Malicious processors are more practical, more ïexible, and harder to detect than an initial analysis would suggest."

https://db.usenix.org/event/leet08/tech/full_papers/king/king_html/

# Attacking network cards

"I've reached my goal of writing a totally transparent firewall bypass engine for those firewalls which are PC-based: you simply overwrite the firmware in both NICs and then perform PCI-to-PCI transfers between the two cards for suitably formatted IP packets (modern NICs have IP "offload engines" in hardware and therefore can trigger on incoming and outgoing packets). The resulting "Jedi Packet Trick" (sorry, couldn't resist) fools, amongst others, CheckPoint FW-1, Linux-based Strongwall, etc. This is of course obvious as none of them check PCI-to-PCI transfers. "

https://lwn.net/Articles/284162/
http://www.links.org/?p=330

# 'Super-secret' debugger discovered in AMD CPUs
# Password-protected feature goes beyond x86

http://www.theregister.co.uk/2010/11/15/amd_secret_debugger/

# Super-secret debug capabilities of AMD processors !

http://www.woodmann.com/collaborative/knowledge/index.php/Super-secret_debug_capabilities_of_AMD_processors_!

# Hidden Debug Mode Found In AMD Processors

http://hardware.slashdot.org/story/10/11/12/047243/Hidden-Debug-Mode-Found-In-AMD-Processors

# A microcode reliability update is available that improves the reliability of systems that use Intel processors

http://support.microsoft.com/kb/936357

# Google: attacking network cards malware, PCI rootkit, PCI rootkits, rootkit firmware, etc.

How did "open source is audited by all" work out of Debian's changes to OpenSSL? Badly, I think. http://www.links.org?p=328

True, but that's not what he is questioning. Given two identical projects that are fairly complex (i.e. an OS kernel) he's saying that just being open source doesn't necessarily provide "more eyes". While I think there is a bit of merit to this, it certainly doesn't hurt to have more eyes possible - especially when you don't have to pay for them.

Agreed, of course. However, the converse is important, too:

Given two identical projects that are fairly complex (i.e. an OS kernel), being closed source virtually guarantees that there won't be 'more eyes'.

But the real question is: How many eyes are enough?

The answer is its own problem: Only one more pair. The tricky part is figuring out whose they are. (Yes, I'm in screaming agreement with what the OP is saying.)

It's a quality issue as much as it's a question of quantity. Ben Laurie, writing about the Debian OpenSSL Fiasco, states:

[I]f the Debian maintainer [who created the bug] had asked the [OpenSSL] developers, then we would have advised against such a change.

So yes, it does matter whose eyes are turned to a particular problem. The difference between FOSS/Open Source and Closed Source is therefore whether the Closed Source company has hired the right people and whether the FOSS project has gained the attention and interest of the right people.

Neither of those situations is guaranteed, but they are not at all equivalent. (Especially when we consider that for many of the best FOSS products, gaining the attention and interest of the right people is done by employing them.) Realistically, FOSS faces better odds of having bugs found and fixed, all else being equal.

My GF's great-grandmother passed away in November. She was very close.

Weepy GF gets onto the web site of a regional Canadian carrier that prides itself on its customer service, selects her flight, and begins to fill out the VISA information. After filling out most of the information she clicks "continue" and *bam* up comes VISA's activation during shopping page (ADS) with a giant "I agree" button under inscrutable masses of legal fine print. She is in a fine state of mind for clicking her life away.

This happens right in the middle of the transaction, with no advance warning. Not on the page before she began filling out the details: to complete this transaction with your VISA card, you will be obligated to click "I agree" to the ADS terms of service, which shifts VISA's liability onto your shoulders and plays havoc with established web security practices and altogether makes the world a shittier place.

All of this under the commercial maxim that instant gratification == learned helplessness. Your average user will blindly click anything during gratification interruptus.

As it happens, my red-eyed GF muttered out loud "WTF is this?". It took me about 30s to get past "HF those sleezy MFs". Then I told her to slam down the virtual circuit on her half-completed web page transaction and start the transaction over again using an aging circuit-switched technology far less suited to rights erosion, and also more expensive for the airline to provide. Real human at the other end. What a PITA.

Brilliant lose-lose for everyone involved.

Two of the links I recorded checked this out:
Links More Banking Stupidity: Phished by Visa
Verified by Visa: British banks phish their own customers - Boing Boing

Redacted portions of an online TOS from a large Canadian bank which has since gone 404.

You agree not to: modify, adapt, sub-license, translate, sell, reverse engineer, decompile or disassemble any portion of the Verified by Visa Website or service or the software used in connection with Verified by Visa.

You agree to immediately notify us by contacting us, as we require in our cardholder agreement with you for a lost or stolen card of any unauthorized use of your password or other verification information, or any other breach of security. You will be liable for any unauthorized activity involving use of your password or Activation Data, until we receive such notice.

Answer me this, Batman:

How is one supposed to notify the bank that you've lost control over the password, when you lose control to a phishing widget embedded in a concealed iFrame?

I wrote that riddle back in November, and I'm no closer now to coming up with the solution. FWIW, this agreement is probably less egregious than the one that came up under ADS, from a different major Canadian bank. Bonus marks for completing this task without first discovering how the service works which violates your TOS.

This whole thing makes me seriously limbic.

Larry Lessig on laws that choke creativity

And on the other side, among our kids, there's a growing copyright abolitionism, a generation that rejects the very notion of what copyright is supposed to do, rejects copyright and believes that the law is nothing more than an ass to be ignored and to be fought at every opportunity possible. The extremism on one side begets extremism on the other, a fact we should have learned many, many times over, and both extremes in this debate are just wrong.

For the good of society, the law ought not to be an ass, and the VISA company ought to not be pushing the matter like a used car salesman at the helm of an invincible glass castle.

How about the other option of not making so many goddam patches? After the Debian OpenSSH debacle, I lost my faith in the Debian "development model" of letting newbs patch core software like OpenSSH for fun. Who try to one-up Theo on security, for crying out loud?

Debian had better rethink the necessity of its myriad patches. So many of the frustrating regressions in Ubuntu are due to some useless patch made to the kernel by downstream.

Is it possible to exploit firmware from the outside, unless the person has enabled remote management and is using the default password?

The latest research seems to indicate that it is indeed possible to exploit weaknesses in network card firmware - or any card on the PCI bus - to traverse firewalls.

If you read all the comments following this rant, you will discover that the person who created the offending patch tried to check it with the OpenSSL devs by posting the patch to the openssl-dev mailing list.

Unfortunately that list is not for OpenSSL devs, instead it is for users of OpenSSL. Therefore only other clueless users saw the patch. To reach the OpenSSL devs one needed to use the openssl-team mailing list instead of openssl-dev.

IMO, this problem was due to a communication problem and it is hard to blame just one person for that. If I had to place blame, I would say the fault was with the poorly chosen names for the OpenSSL mailing lists.

No, he posted a question openssl-dev, which is a mailing list for people writing software that uses OpenSSL. This OpenSSL developer doesn't read it and that's similar with most open source project - developers often don't read mailing lists for end users.

What's more, that mail doesn't contain a patch. It contains a misleading question with two lines posted in isolation. An actual patch, submitted for an actual code review, would almost certainly have revealed the problem via context.

You don't change crypto code of all things based on an idle question on a mailing list populated mostly by users. What's next, changing the kernel scheduler based on a conversation in #kernel-newbies?

Ben Laurie of OpenSSL/Apache puts it into some context:
http://www.links.org/?p=327#comment-176642

Obviously some of the OpenSSL devs probably should've been like "zOMG, SITUATION FUBAR", but it wasn't a formal code review being requested, more of a "hey, what do you think of this and this?" and the patch was never submitted to upstream.

One of the OpenSSL developers (or at least, that's what I infer) puts it in even more general terms:

However, I can't help wondering if some fault may arguably lie with the OpenSSL coders. I mean... by his own admission:

(Emphasis mine)

So, since it's unusually doing something that looks an awful lot like a Cardinal Sin, did this block of code include a prominent:

I mean, if you're going to write code that basically looks like a duck, walks like a duck and quacks like a duck, and which you know is going to head downstream toward a huge bunch of duck-hunters, it's really a good idea to add a big visible note saying THIS IS NOT A DUCK.

OpenSSL happens to include a rare case when its OK, or even a good idea: its randomness pool. Adding uninitialised memory to it can do no harm and might do some good, which is why we do it.

Okay, I started investigate. A number of things don't ring fully true. They are very careless about discussing physical and local security for the whistleblowers. I found this worrying but decided to try to correct it. I noticed that they claim to be a normal open wiki and so I tried to sign up... no sign up page on the login page. Then I tried forcing the link by copying from wikipedia: https://wikileaks.org/wiki/index.php?title=Special :Userlogin&type=signup&returnto=Wikileaks:Main_Pag e "You are not allowed to create an account / To be allowed to create accounts in this wiki you have to log in and have the appropriate permissions.". https://wikileaks.org/wiki/Advisory_Board shows that the Advisory board has some credibility, but does it really exist? Interestingly several of them have blogs http://iq.org/ http://www.wangdan1989.com/ http://www.links.org/ but I haven't been able to find any references to Wikileaks. Why is there no information from the EFF or other similar bodies?

Maybe somebody needs to start a defamation search engine, which links defamation to defenses against same, and lets people compare to see which is more plausible.
-russ

Dilbert_ writes "Since most dot com domains of the form www.[common english word].com are taken today, you could theoretically surf around using just a dictionary. Now you can search the web from a page that will will automatically generate a fresh load of links, based on a dictionnary. " For some reason this amuses me greatly.