Slashdot Mirror

Interesting read, thanks.

A quick google turned up an interesting article on this: How the PS3 hypervisor was hacked.

Here you go, some examples:
http://www.vupen.com/blog/20120904.Advanced_Exploitation_of_Xen_Sysret_VM_Escape_CVE-2012-0217.php
http://rdist.root.org/2010/01/27/how-the-ps3-hypervisor-was-hacked/

So DSA keys are safer it would seem.

DSA has it's own problems. Most notably merely USING your key to generate a signature with a broken random number generator can be enough to reveal it to an attacker. Thankfully PGP doesn't use openssl and while it's POSSIBLE to use the same keys for ssh and pgp the impression I got is that not many people do.

http://rdist.root.org/2009/05/17/the-debian-pgp-disaster-that-almost-was/

Yes, HDCP happens right at the I/O chip, and you can extract unencrypted raw video bitstreams in a variety of ways. All involve actually opening up the receiver device and soldering on wires.

Sometimes yes, sometimes not. There are plenty of devices these days (both sources and sinks) that use SoCs with an embedded HDMI interface, including HDCP. There are no unencrypted video lines to tap in those.

The contents of these vendor ROMs are typically unique to each vendor and their contents are not even disclosed to the vendor.

The contents are unique for each individual unit. Doing otherwise would be a violation of the HDCP licensing agreement. Each specific instance of a device has its own unique key set.

They do not contain the master key, but are somehow related to it.

They contain a randomly picked KSV (40-bit value with 20 zeroes and 20 ones) and the matrix product of the master key with that KSV (row-wise or column-wise, depending on whether the device is a source or a sink). That is how the master key works.

FWIW, this device isn't a man-in-the-middle attack: it does not at all depend on the sink device supporting HDCP. It's an HDCP stripper, plain and simple. They used the master key to generate their own device key set (or maybe even randomly generate one on each time you use it, which is perfectly acceptable). The output doesn't use HDCP and the receiving screen has no idea that the content was meant to be encrypted. Of course, it's perfectly possible to man-in-the-middle an HDCP stream and dump it out to a third connection, but it's pointless because there is no need to have a real device to authenticate, when you can just authenticate yourself using a valid random key made from the master key. Once you have the master key you gain nothing by having an authorized HDCP device available on the receiving end.

On the other hand, there is one use case for an actual man-in-the-middle attack that does not dump out or break the DRM at all: the Chumby NeTV. It snoops on authentication to compute the shared key used by the source and the sink, and then uses it to encrypt overlay content and merge it into the image. Since the original image is never decrypted, this legally does not break the DMCA, and thus the MiTM serves a legal purpose, not a technical one (it would arguably be easier to just strip the HDCP off of the source and have the output be unprotected and just merge the overlays with that, but that would not be legal).

FYI, a series of blog articles on this:
http://rdist.root.org/2010/05/03/why-buffer-overflow-exploitation-took-so-long-to-mature/

What trouble and expense? TLS (SSL is obsolete) is only expensive if you need to get your certificates signed by a commercial CA i.e. if you are interacting with random people who are not affiliated with you or your organization. If you are only deploying TLS for internal purposes, just maintain your own internal CA and deploy your internal signing key to all of your organization's systems.

Having your own CA raises the distribution problem, which is different or at least flaky for virtually every browser / OS combination, and you're still running on what may as well be a compromised system so TLS is irrelevant since the attacker can just root the system and grab keypresses.

The best solution short of buying laptops and putting epoxy in the ports is mastering a Knoppix CD. You can get a kiosk-style browser loaded with only your org's CA and a TLS client certificate. If you can distribute your own CA certs, you may as well also distribute client certs. You can disable storage drivers except for ramFS. You can block everything but 443 outgoing. You can verify your server before launching the browser.

You now have a simple procedure to force users to access your site properly. There is no possibility of a MITM by creating a fake site from a misspelling, and rather than clicking through security warnings, you can display a dialog telling them that something is seriously wrong and who they need to call, with no way of just clicking through the warnings.

You have two factor authentication; the client cert on the CD and password are separate factors. You have honest to god protection from CA fraud since only the CA you created is loaded. The only ways (I know of...) to compromise this setup are a hardware attack, user completely bypassing you by booting in a VM, or a rootkit in BIOS or the hypervisor.

Having not seen the technical details of this implementation issue before, I googled it, and found http://rdist.root.org/2010/11/19/dsa-requirements-for-random-k-value/. I don't design my own signature implementations (I just use openssl), but its conceivable that I might need to at some point, so I like to keep up on the technical details behind such cracks; in order to avoid making the same mistakes.

The better, original article has more detail. Not an exhaustive description, but enough for an interested amateur to understand how it could have been more sophisticated. The short version:

What Stuxnet does: Check if the system you're on meets certain parameters (controlling a bunch of centrifuges, etc). If so, execute the payload.

What it could have done: Check the parameters of the system, and assemble them into a key. Try using it to decrypt the payload. If the parameters are correct, it will successfully decrypt. Execute it.

In the latter case, the payload is encrypted, and can't be decrypted unless you guess the parameters of the system on which it's supposed to execute. (Or, at least, guess enough of the parameters to let you brute-force the rest of the key.)

This is the article worth pointing to on the subject: http://rdist.root.org/2011/01/17/stuxnet-is-embarrassing-not-amazing/, not the bullshit linkbait threatpost.com(MERCIAL) "article".

From http://rdist.root.org/2010/11/19/dsa-requirements-for-random-k-value/comment-page-1/#comment-6413 :
"You wouldn’t even have seen discussion inside Sony. Their corporate culture is very stovepiped, quite dysfunctionally so since what would be regarded as normal communication channels in other companies (even the highly regulated ones that exist in Japan where as an engineer or developer you’re given a task and perform it to the best of your ability without thinking of questioning any of it) simply don’t exist. So for something like this development team A would have been handed a fait accompli by development team B without any ability to question it, or even an ability to provide feedback if they noticed a problem. In fact the first that one team may hear about some new techology is when it gets shipped to them from some other development group (people complain about the lack of technical info from Sony to work with the PS3 but it’s not much better for people working inside the company, who have extreme difficulty getting the information they need).

So not only would Sony not have employed Root Labs to look at this, they wouldn’t have involved anyone else at Sony outside the narrow stovepipe that worked on it."

Just read this:
http://rdist.root.org/2010/01/27/how-the-ps3-hypervisor-was-hacked/
The recent usb hack didn't restore OtherOS. It was all about piracy, hence the $150 price tag and piracy advertisement.
There was no people's crackerz army that took revenge against Sony.

The faults described by the paper are so ... what's the word ... specialized that it challenges believability.

Just a heads up, these types of attacks are not new. Your skepticism is in the right place, but people have been exploiting timing analysis, power analysis, and differential fault analysis for about two decades.

So, not only do attackers have to know exactly, to the microsecond, when the system under attack is computing the RSA algorithm, they also have to be able to vary the voltage to the CPU

You're describing excatly what engineers grit their teeth at being called an 'engineering problem'. Count clock cycles, some of which may even be under your control. If you think it is out of the realm of possibility to construct machinery that runs faster than the equipment you are trying to break, you're not skeptical enough.

The paper asserts that the probes can be done without leaving any trace. I don't know about the authors, but the voltages on my computers are monitored by software and excursions logged so that I can know if/when there are problems. Since the RSA-breaking technique requires substantial exploration of the response to voltage tweaks, it is likely to be detected by a decent monitoring program.

Your voltages are monitored only to a certain level of exactness. If you think that 3.3V line is 3.300000V, I have a fine bridge for sale. As for detection, as mentioned earlier in the comments, there are already standards in place for detection of such attacks. That doesn't mean they are in place now. A more recent example can be found here.

George connected an FPGA to a single line on his PS3’s memory bus. He programmed the chip with very simple logic: send a 40 ns pulse via the output pin when triggered by a pushbutton. This can be done with a few lines of Verilog. While the length of the pulse is relatively short (but still about 100 memory clock cycles of the PS3), the triggering is extremely imprecise. However, he used software to setup the RAM to give a higher likelihood of success than it would first appear.

In summary, you are talking out of your ass, but I ain't mad at ya.

A cleverer backdoor would have been a weak custom MAC (say, just the H(M) + secret). Then it'd still be exploitable, yet not obviously bad.

This article goes into the reasons why HMACs are constructed the way they are, and about how naive constructions can be exploited.

If you're looking for more technical details on the attack, slides, etc., they can be found on his blog.

Hi twitter.

No, I use Debian, so a team of people have done that for me

How's that working out for you so far?

The SPDC VM is not Java. I don't think you've asked the right questions of your "people at IBM who wrote the JVM used to play BD+". Here's Avi Rubin describing the SPDC VM:

The SPDC Virtual Machine specification defines a MIPS-like instruction set consist- ing of 59 standard machine operations (along with several reserved and vendor-defined operations.) Each machine instruction is encoded as a 32-bit value. The Virtual Machine provides content code with two memory areas, one for the content code and data, and another undefined area which can be used as defined by the device manufacturer. The VM also defines a set of 32-bit registers, a Program Counter, and an Instruction Filter, which is applied to instructions before execution.

(In case you're wondering, the JVM is not a "MIPS-like instruction set on 32-bit registers with a Program Counter and an Instruction Filter" --- but that wouldn't stop you from implementing such a VM IN Java, just as the JVM is itself rarely implemented in hardware --- thus the "V" in "VM".)

The person I know who's involved with BD+ co-designed BD+.

From the comments section, Nate Lawson has posted his response to Joanna:

http://rdist.root.org/2007/06/28/undetectable-hype rvisor-rootkit-challenge/

From The Tao Of Programming:

T h e A n c i e n t M a s t e r s
B o o k T w o
Thus spake the master programmer:
"After three days without programming, life becomes meaningless."


More I cannot say. The tao must be experienced for true understanding to dawn.
---