room topic changed to The DMZ: The first breach costs you an arm.... [double-entendre] [doughnuts] [food] [libations] [nono-php] [no-singing] [rory] [security]
@TerryChia not looked at that one yet, but I'll add it to my list :) Hoping to get some research time in a couple of weeks to start looking at stuff properly...
@TerryChia interesting thought, that will be one of the key bits. Though to an extent if you an install a library, you'll probably use it at least once, so code execution on instantiation would work too...
One large issue with that is that if there's code execution during runtime it's usually in the context of a normal user. By default Python's package manager requires root to install so code execution during install directly leads to root.
So you know how you debug a program, and put a bunch of print statements in. And when you run the program you're like, "Damn it I forgot the \n's!!"? Now imagine you put debug statements into a kernel, built it, packed it and flashed a device and then checked for the print statements only to realize you didn't put \n's in.... >.<
I give it until noon tomorrow before this bug has a name, and we have a new tag and ten questions that are variations on "how to exploit [x]" and "is [y] vulnerable to [x]"
@Xander ooh well as these things tend to have names that sound like metal bands "heartbleed", "shellshock", "sandworm", we should agitate for the new one to be called "metaltech" :op
@AJHenderson All we know is a commit in OpenSSL source code that deactivates support for the encrypt-then-MAC extension (RFC 7366) for SSL 3.0 (all algorithms) and for RC4 specifically (in TLS 1.0+).
It is not confirmed that this commit is actually related to the vulnerability.
hey @AviD as you're right into getting low-level understanding of hipster languages, here's some schtick on how ruby is implemented in C for you. omniref.com/ruby/2.2.0.preview1/symbols/…
@ThomasPornin well, I'd be happy if it is just another Open-SSL issue, that's relatively easy for me to fix, though if it is generically related to RC4, even in TLS, then I might be a bit worried
The commit is in fact justified: RFC 7366 explicitly denies applicability of encrypt-then-MAC to SSL 3.0; and also to stream ciphers. The commit merely aligns with the RFC.
@Xander As a shot in the dark, I'll say it is in the CBC padding.
2
With SSL 3.0, the padding consists in n+1 bytes, the last of which having value n.
I suppose it isn't the end of the world if I simply have to turn off SSL3.0 support tomorrow. I already have a pretty limited set of use cases for it on my server
Thus, with SSL 3.0, there is some room for modifications that will not impact the decrypted data (since they fall in the padding bytes whose value is ignored), but that will impact the decryption of the next record, since the encryption of the last padding block serves as IV for the next record.
So at that point I'll try to substitute the first block of the next record with the encryption of a block that has identical contents except for the first byte, that is unknown and that I want to guess.
@ThomasPornin I'm having trouble seeing what the end goal really is. If your end goal is to derive the key, or predict plaintext values wouldn't you need a fairly high number of records within the same session?
Attacker is both inside (hostile Javascript) and outside (has control of the WiFi hotspot). Attacker wants to get the victim's cookie on some other site.
2
Hostile Javascript issues a GET HTTPS request to the bank site; the request contains the cookie. Encryption is CBC, let's say with 3DES. In the stream, attacker arranges for the last byte of the cookie to be the first of an 8-byte block.
The attacker knows the bytes immediately after the cookie (start of the next HTTP header).
So attacker sees y = E((X || c) xor d) where X is the last byte of the cookie, c is the next (known) 7 bytes, and d is the previous encrypted block (also known).
Attacker then instructs his Javascript to issue a request including the bytes A || c such that A is his guess of the unknown byte, and that sequence happens as first block of a record.
Attacker also arranges for the previous record to have length such that the padding for the previous record has length 8 bytes.
The attacker intercepts and alters the two records (the one that contains 'A || c' and the previous one).
He replaces the last block of the first record with d, and the first block of the second record with y.
Replacement in the first record has probability 1/256 of being accepted by the server, because of the SSL 3.0 padding (it depends on whether decryption yields a final byte of value 7, the other bytes being ignored).
The attacker can see that by just setting a small delay between sending of the two records, just to see if the server complains or not.
If the server does not complain, then it will accept the subsequent record, or not, depending on whether A = X or not.
Thus, with an average of 128*256 calls, the attacker guesses the last byte of the cookie.
He then iterates with the previous one, and so on.
There are details to adjust in the description above (data after A || c must match the modification of the first encrypted block of the second record) but it seems that it works on the paper.
The root cause: SSL 3.0 CBC padding allows for a lot of modifications that will be ignored upon decryption, which gives leverage to play IV-based games.
In TLS 1.0 all the padding bytes are fixed and the implementations must check them, so this attack does not work.
RFC 7366 (encrypt-then-MAC) would actually help a lot against these attacks. But it is not defined for SSL 3.0.
That's it. We'll see tomorrow how things turn out.
@RоryMcCune I don't have a twitter account. If you want, you may answer in my name: "my guess is a BEAST-like attack that abuses the ignored bytes in SSL 3.0 padding (1/256 chance of unnoticed alteration, modifies IV for next record)".
Workaround: deactivate SSL 3.0 support (in browsers or servers or both).
It's them words. I like them. I don't want to see them tortured and crushed into an arbitrary size limitation designed to fit the average attention span of Internet users.
@Xander @ThomasPornin well there are times when you just get torn between "what linguistic crime am I going to commit here to get my point over in <140 chars"
@ThomasPornin yeah I often compare pen testing to CTFs in the same way. With a CTF you know there's a problem there, with a pen test you could be banging your head up against a brick wall
completely changes the mindset (well does for me anyway)
@ThomasPornin they're useful for practicing techniques, so that when you find them in the live you know what to do, but can give an artificial expectation if that's all you've done..
@ThomasPornin although there's some odd randomness in there twitter.com/search?q=pornin&src=sprv actually shows quite a few tweets... you'll get social media stain if you're not careful :op
@ThomasPornin What would be grand is a blog post on it - just expanding your brief chatroom summary. I'm definitely not qualified, but if you (or one of our other crypto folks) wanted to draft up a blog post for publication tomorrow as a place to go for all (insert name of new SSL3 vuln here) questions we could ping that around the intarwebsphere
@RоryMcCune I don't have a twitter account. If you want, you may answer in my name: "my guess is a BEAST-like attack that abuses the ignored bytes in SSL 3.0 padding (1/256 chance of unnoticed alteration, modifies IV for next record)".
Not sure whether it's significant, but I posted Thomas's summary to the security mailing list, and the official announcement went live 15 minutes later. Pornin might have moved the timetable by guessing it early, or perhaps it was just a coincidence.
For reference, here are 3 original announcements: http://www.openssl.org/~bodo/ssl-poodle.pdf http://googleonlinesecurity.blogspot.ie/2014/10/this-poodle-bites-exploiting-ssl-30.html https://blog.cloudflare.com/sslv3-support-disabled-by-default-due-to-vulnerability/
damn you markdown
Also, I like how cloudflare says they're "continuing to track this announcement as it breaks, even though they had their blog post up BEFORE the announcement.
The attack indeed uses the SSL 3.0 CBC padding. It turns out to be a bit simpler than what I was explaining (though my technique would have worked, too).
Canonical question regarding the recently disclosed padding oracle vulnerability in SSL v3. Other identical or significantly similar questions should be closed as a duplicate of this one.
What is the Poodle vulnerability?
I use [product]. Am I affected?
Is [product] vulnerable to the Poodl...
A few other sites (SF comes to mind) typically maintain "canonical" entries for popular questions. This way you don't end up with a bunch of incomplete answers scattered across dozens of questions.
We do it too, sometimes, but usually we just link to the first person to ask, and often their question is too specific.
Given the various lengths of RSA key pairs (1024, 2048, 4096) what are the odds of two users having generated the exact same private key?
Canonical question regarding the recently disclosed padding oracle vulnerability in SSL v3. Other identical or significantly similar questions should be closed as a duplicate of this one.
What is the Poodle vulnerability?
I use [product]. Am I affected?
Is [product] vulnerable to the Poodl...
