hardly. when you type in english, you think of the word and you type in the letters of that word.
when you type in japanese, you think of the word, then you have to translate it at least once (maybe twice) in your head before you have a list of roman letters to type. Then you have to assist the computer in guessing the reverse of the translations you just did. certainly, much of this is simple for the typist, and for the computer, but it's fundamentally different from typing a roman language.
I'm betting you'll be saying that right up until the point that your app gets rejected for some arbitrary reason and you whole business plan goes down the toilet.
you can't find WUXGA (1920x1200) on laptops smaller than 17". it used to be (for the last 7 years) that you could get a portable 15.4" WUXGA at a reasonable price. not any more...
you can't get WUXGA (1920x1200) displays on a laptop smaller that 17" any more. the inspiron was the 1st laptop to have such a display, it was available back in 2003...
You are wrong. This vulnerability is actually an artifact of the underlying encryption algorithm, and as such other products are also vulnerable, e.g. JSF (for which attacks were demonstrated before the ASP.NET one) and Ruby-on-Rails.
the vulnerability isn't in the encryption algorithm, it's in the implementation of the CBC operation of the block cypher.
It allows you to retrieve the full key. And the key is symmetrix[sic], meaning that you can both decrypt and encrypt.
No, the oracle doesn't give you the key. The key and the encryption algorithm are irrelevant. The oracle allows you to retrieve the IV for a given cypher block, but most importantly it allows you to encrypt/decrypt without the key.
The attacker can gradually learn the exact machine key by manipulating something he knows to be encrypted. By padding the encrypted text from the end, and watching to see whether the server decryption fails or he hits something which *can* actually decrypt (but which may causes the app to fail), he can learn something about the key. Presumably this is because he knows that the last part of the key is used to encrypt the last part of the text. Anything encrypted will do. Even the timing of the failure may offer the attacker valuable information, e.g. failure to decrypt results in faster fails than the application trying to run with something which actually decrypted without error only to fail a little later.
The above is mostly correct, but again, the attacker doesn't learn the key, just the IV required to generate correct padding.
This is not specific to ASP.NET. But ASP.NET happens to use the machine key to encrypt authentication tickets.
The built-in authentication methods do encrypt the ticket with the machine key. However...
If you learn the machine key then you can fake any identity.
This is not necessarily true. The identity placed in the ticket is generated by the application. If the developer chooses a predictable form of ticket, then, yes, you can generate tickets for other users. However, a developer can easily use a non-predictable ticket format to thwart this part of the attack.
As this is a standard algorithm, expect the ASP.NET fix to be a sanity check (hash/signature) on the entire ciphertext so that it can reject it up front before even attempting to decrypt. Ruby-on-Rails has a similar method where you must explicitly request verify and decrypt instead of just decrypt.
They could fix this just by hiding the padding exception, and maybe adding a little random delay. It'll be interesting to see what changes they made, in 45 minutes or so...
the padding oracle vulnerability allows you to do two things: 1) decrypt cyphertet that has been encrypted using the site's machineKey 2) encrypt arbitrary plaintext as if you knew the machineKey
it doesn't give you the machineKey, but you can encrypt/decrypt as if you had it.
There's another vulnerability that allows you to download arbitrary files (even 'protected' ones) if you are able to encode plaintext with the site's machineKey. ScriptResource.axd is used by asp.net to compress/bundle scripts, and it takes a parameter that is encoded using the machineKey. The assumption is that the machineKey is secret, so it bypasses the regular pipeline that includes the checks for protected files. However, even though the attacker doesn't know the machine key, he is able to use the oracle to correctly encode the parameter to ScriptResource.axd, download web.config and learn further secrets.
Further, if the site encodes authentication tickets into the cookies in a predictable manner, the attacker can use the oracle to forge other valid authentication tickets. This is the attack that's shown in the video.
The vulnerability DOES NOT REQUIRE the stack traces in order for it to work. Telling people that this is the case is extremely dangerous and irresponsible because it leads people to believe that they are safe WHEN THEY ARE NOT!
The exploit only needs to know that something went wrong. It doesn't need to know what went wrong. All it needs to know is that the response for a correct padding byte is different than the response for an incorrect one. The difference between a '500' and '404' in the HTTP response header is sufficient, and the 'production' error pages certainly have this difference.
The attack requires the ASP.NET error page that shows exception information to be enabled.
NO! NO! NO!
This is wrong, and dangerous. There is no such requirement, the HTTP status code is sufficient. Actually, the timing is sufficient, but slightly harder to exploit.
No sane person will leave it like this in production let alone that it is turned off by default.
This is correct, and, unfortunately, why the 1st statement is so dangerous.
Assuming that your site is safe just because you've followed best practices is WRONG! You MUST apply the fix in ScottGu's post immediately!
Slashdot Mirror
better still: cat /dev/urandom > /dev/hda # eat my highly-encrypted shorts
does this mean that they'll be able to print graphene interconnects between transistors?
it's all about the software.
you buy x86 to run OSS on linux/bsd, you buy sun/ibm to run oracle/db2/java, you buy windows to run microsoft stack.
you wouldn't in your right mind run OSX unless you had to, and there's nothing really that requires OSX on the server, except maybe WebObjects, pfff.
In the data center, where function is everything, and form is irrelevant, apple brings nothing.
That person you obviously think I am? That's not me.
news flash people:
Google isn't congress. (yet)
The 1st amendment doesn't apply. Google can censor whatever it wants on its properties.
hardly. when you type in english, you think of the word and you type in the letters of that word.
when you type in japanese, you think of the word, then you have to translate it at least once (maybe twice) in your head before you have a list of roman letters to type. Then you have to assist the computer in guessing the reverse of the translations you just did. certainly, much of this is simple for the typist, and for the computer, but it's fundamentally different from typing a roman language.
I'm betting you'll be saying that right up until the point that your app gets rejected for some arbitrary reason and you whole business plan goes down the toilet.
"Yeah, but it won't happen to me."
that's exactly what the Polish Jews said...
write once, hack everywhere.
they also support real DOS, too. command.com, anyone?
yeah, those 120px is 10 lines of text. that's a whole lot of scrolling I don't have to do...
you can't find WUXGA (1920x1200) on laptops smaller than 17". it used to be (for the last 7 years) that you could get a portable 15.4" WUXGA at a reasonable price. not any more...
you can't get WUXGA (1920x1200) displays on a laptop smaller that 17" any more. the inspiron was the 1st laptop to have such a display, it was available back in 2003...
My two last laptops (dell 8500 & D830) have both had 15.4" WUXGA (1920x1200).
The 8500 came out in early 2003.
You cannot find WUXGA displays on laptops smaller than 17" any more.
This is crazy. What is the world coming to?
When my D830 finally breaks beyond repair (I've already replaced the motherboard), I'm going to go live in a cave...
You are wrong. This vulnerability is actually an artifact of the underlying encryption algorithm, and as such other products are also vulnerable, e.g. JSF (for which attacks were demonstrated before the ASP.NET one) and Ruby-on-Rails.
the vulnerability isn't in the encryption algorithm, it's in the implementation of the CBC operation of the block cypher.
It allows you to retrieve the full key. And the key is symmetrix[sic], meaning that you can both decrypt and encrypt.
No, the oracle doesn't give you the key. The key and the encryption algorithm are irrelevant. The oracle allows you to retrieve the IV for a given cypher block, but most importantly it allows you to encrypt/decrypt without the key.
The attacker can gradually learn the exact machine key by manipulating something he knows to be encrypted. By padding the encrypted text from the end, and watching to see whether the server decryption fails or he hits something which *can* actually decrypt (but which may causes the app to fail), he can learn something about the key. Presumably this is because he knows that the last part of the key is used to encrypt the last part of the text. Anything encrypted will do. Even the timing of the failure may offer the attacker valuable information, e.g. failure to decrypt results in faster fails than the application trying to run with something which actually decrypted without error only to fail a little later.
The above is mostly correct, but again, the attacker doesn't learn the key, just the IV required to generate correct padding.
This is not specific to ASP.NET. But ASP.NET happens to use the machine key to encrypt authentication tickets.
The built-in authentication methods do encrypt the ticket with the machine key. However...
If you learn the machine key then you can fake any identity.
This is not necessarily true. The identity placed in the ticket is generated by the application. If the developer chooses a predictable form of ticket, then, yes, you can generate tickets for other users. However, a developer can easily use a non-predictable ticket format to thwart this part of the attack.
As this is a standard algorithm, expect the ASP.NET fix to be a sanity check (hash/signature) on the entire ciphertext so that it can reject it up front before even attempting to decrypt. Ruby-on-Rails has a similar method where you must explicitly request verify and decrypt instead of just decrypt.
They could fix this just by hiding the padding exception, and maybe adding a little random delay. It'll be interesting to see what changes they made, in 45 minutes or so...
the padding oracle vulnerability allows you to do two things:
1) decrypt cyphertet that has been encrypted using the site's machineKey
2) encrypt arbitrary plaintext as if you knew the machineKey
it doesn't give you the machineKey, but you can encrypt/decrypt as if you had it.
There's another vulnerability that allows you to download arbitrary files (even 'protected' ones) if you are able to encode plaintext with the site's machineKey. ScriptResource.axd is used by asp.net to compress/bundle scripts, and it takes a parameter that is encoded using the machineKey. The assumption is that the machineKey is secret, so it bypasses the regular pipeline that includes the checks for protected files. However, even though the attacker doesn't know the machine key, he is able to use the oracle to correctly encode the parameter to ScriptResource.axd, download web.config and learn further secrets.
Further, if the site encodes authentication tickets into the cookies in a predictable manner, the attacker can use the oracle to forge other valid authentication tickets. This is the attack that's shown in the video.
dream on
WebResource.axd provides the oracle. given the oracle, ScriptResource.axd provides the local files.
mod parent up
ARGH! NO!
Why do you guys keep reiterating this crap.
The vulnerability DOES NOT REQUIRE the stack traces in order for it to work. Telling people that this is the case is extremely dangerous and irresponsible because it leads people to believe that they are safe WHEN THEY ARE NOT!
The exploit only needs to know that something went wrong. It doesn't need to know what went wrong. All it needs to know is that the response for a correct padding byte is different than the response for an incorrect one. The difference between a '500' and '404' in the HTTP response header is sufficient, and the 'production' error pages certainly have this difference.
the real question is why are prices in the west so high?
this is irrelevant and misleading, the exploit does not require the stack trace pages to be enabled in order to be effective.
the http status code is enough error information in order for this exploit to work. RemoteOnly is irrelevant.
it's not just about cookies, it's about extracting the machineKey. for 99.9% of ASP.NET sites that's a complete disaster.
if you admin ASP.NET and you think this doesn't affect you, then you're probably wrong.
the http status code in the generic error message is sufficient for this exploit to work.
NO! NO! NO!
This is wrong, and dangerous. There is no such requirement, the HTTP status code is sufficient. Actually, the timing is sufficient, but slightly harder to exploit.
This is correct, and, unfortunately, why the 1st statement is so dangerous.
Assuming that your site is safe just because you've followed best practices is WRONG! You MUST apply the fix in ScottGu's post immediately!