
Theo de Raadt summarizes the OpenBSD IPSec "backdoor" situation - there
http://marc.info/?l=openbsd-tech&m=129296046123471&w=2
======
zdw
The meat of it:

    
    
      (g) I believe that NETSEC was probably contracted to write backdoors as alleged.
    
      (h) If those were written, I don't believe they made it into our tree. 
    

As an OpenBSD user, the big benefit of all of this is that the code in
question got a lot of audit attention.

And that the next version of OpenBSD will probably have a funny song about
this on the end of CD #2

~~~
tehjones
We might also get some commentary with this next release.

------
lenni
People often complain about his erratic and uncontrollable behaviour, but I
find Theo de Raadt comes across entirely reasonable in this message.

What's the history there?

~~~
tptacek
I'm not sure I think that it's reasonable for Theo to suggest that one of his
key contributing developers was "not fully transparent" about whether he wrote
backdoors in the OpenBSD IPSEC code. Theo has no evidence to implicate Jason.
Jason served the OpenBSD project with distinction. The matter at hand relates
to Jason's personal honor. The instigator of the controversy is a known high-
drama person.

I might have hoped to see him stick by his guy.

But then, that's Theo. You take the good with the not-so-good.

~~~
zedshaw
But, I thought you weren't supposed to take people's "high-drama" into account
when evaluating statements and arguments, and judge them entirely on the
facts. Isn't that ad hominem as you love to point out?

~~~
tptacek
Personally, Zed, I don't give a shit about "ad hominem"; my "hominem" has been
the "ad" of many an "arguendo", just like you, and (unlike you, I know) my
take is pretty much "that's life in the big city". So, I don't hold myself to
this standard of not considering the source in arguments and controversies,
even though I recognize the virtue of doing so. I'm a manifestly imperfect
person.

But I'm not talking about rhetorical purity here. I'm talking about a comment
that implies Theo gave a reasonable (maybe even classy) response to the
situation. Put yourself back in the position of being a lead dev at Bear.
Imagine someone accused one of your better developers of, say, fraud. What's
the standard you set for yourself for sticking by your people? From your
demeanor, my guess is your standard for loyalty to your own people is even
higher than mine.

And that's my point here. How well is Theo acquitting himself here? He's not
doing terribly. He's not necessarily doing great.

But hey, either way, I'm out here with my name signed to my posts. If it turns
out Theo was justified in questioning how Jason handled this, everyone can
look this post up and hoist me with it down the road. I would concede up front
that this is kind of not a whole lot my business; I have a minor, historical,
emotional attachment to it and nothing more.

You brought it up, I responded. There you go.

------
tptacek
You may find yourself wondering, "what is this CBC oracle bug Theo keeps
talking about?". Especially if you've paid attention to security news this
year, where "CBC padding oracle attacks" demolished Java Server Faces and
ASP.NET security. I am here to help!

First, the tl;dr: this flaw is _not_ as bad as a CBC padding oracle. It allows
an attacker with continuous on-line access to a vulnerable target to conduct a
slow, online dictionary attack against all previous ciphertext blocks. Given,
say, a dictionary of passwords, and incurring packet I/O for each guess, you
could discover whether a given ciphertext block encrypts any entry in the
dictionary.

CBC is a way ("the" way, really) to take something like AES that works in
128-bit blocks and apply it across an arbitrarily long stream of data.

The naive way to do this (called "ECB") is simply to apply AES over and over
in 16 byte increments. This sucks for two reasons: first, blocks can be
shuffled around or replayed, because each is encrypted in isolation, and
second because the same plaintext always encrypts to the same ciphertext ---
so if you know the plaintext for a specific block, you can see if that block
has ever occurred anywhere else.

CBC fixes that problem by XORing each plaintext with the previous ciphertext
block; it "chains" all the blocks together. This neatly addresses both those
problems; you can't simply look for repeating patterns because the same block
encrypts to infinitely many different ciphertext blocks. Go CBC!

The one tricky thing about CBC is what you do with the first plaintext block.
There's no previous ciphertext block to XOR it with. The answer is what's
called an "initialization vector" (IV), which is one of the worst names in
crypto. All the IV is is a fictitious zeroth ciphertext block. It's a
parameter to the CBC construction; when you use a library, it'll ask for the
cipher ("AES"), the key size (128 bits), the mode ("CBC"), and the IV.

Here's the thing about the IV: it's conceptually ciphertext. It's a public
value. Anybody can see it. The only thing it's not supposed to be is
predictable or repeatable.

The way you're supposed to do the IV is very simple: you generate 16 random
bytes from your CSPRNG, use them as the IV, and then tack those 16 random
bytes to the front of your message so that the recipient can strip them off
and use them as the IV.

Here's what OpenBSD (and SSH2, back before 2004) did instead: each time it
encrypted a message, it used the last ciphertext block as the IV for the next
message.

This makes perfect conceptual sense! Think about it: what they are basically
do is encrypting in one long, unending CBC stream. It's hard to see how that
could even be a flaw, because a _real_ ciphertext block seems stronger than an
artificial one.

Turns out, no. Here's where that goes wrong: attacker sees a message go across
the wire. Attacker has the last ciphertext block from that message. Attacker
now knows the IV for the next message _before the message is encrypted_.
Here's what can happen: if attacker can get the target to encrypt something
for it†, the attacker can use for that block _known-iv_ XOR _cipherblock-
prior-to-any-target-block_ XOR _guessed-plaintext-of-target-block_. The target
is going to XOR the known-iv into that block (it's the IV, after all), so they
cancel each other out. The block prior to the target block is going to cancel
out the CBC XOR for the target block. So, what you're left with is the ECB-
style encryption of the target block; if you feed _iv_ XOR _previous-
cipherblock_ XOR "YELLOW SUBMARINE" to the target, you can tell if the target
block was "YELLOW SUBMARINE", because they'll match.

The "oracle" here is the condition that the server will encypt a block of
plaintext for the attacker, thus revealing the associated ciphertext. The
"vulnerability" is that by pre-disclosing the IV before using it, that oracle
can be used to attack any previous cipherblock.

This is a neat attack, but also a total pain in the ass to use, and certainly
not an FBI backdoor in OpenBSD IPSEC.

A nit about Theo's message:

This is not a complete summary of what's been discovered about OpenBSD's IPSEC
stack. Marsh Ray also discovered that sometime back in 2003, OpenBSD
discovered a _serious_ vulnerability in its IPSEC stack: they weren't
verifying ESP authenticators! This was due to a straightforward bug in
Angelos' original code to handle crypto accelerator hardware, and it was fixed
in 2003, and that's presumably why Theo didn't mention it.

But Theo is missing the point. We're not simply interested in whether OpenBSD
is vulnerable _today_. We want to know if there's any evidence that the IPSEC
stack was _ever_ tampered with, and particularly around the time frame that
Greg Perry suggested that it was. Worse still, OpenBSD had what appeared to
be†† a very serious security flaw, and they fixed it without telling users.
OpenBSD users do have a right to ask the question, "hey, what gives?".

† _It turns out that this is very often easy to do! For instance, the attacker
might be able to invoke a web app on the target and get it to send a database
query across an IPSEC link; by playing with the lengths of the input, the
attacker can coerce the target into sticking a specific piece of attacker-
controlled data at the beginning of an IPSEC packet. Just one example._

†† _We don't know if any particular configuration of OpenBSD with or without
hardware accelerators in any particular release of OpenBSD had this problem
exploitably, although it sure looks like they did._

~~~
antirez
> Here's the thing about the IV: it's conceptually

> ciphertext. It's a public value. Anybody can see it.

> The only thing it's not supposed to be is predictable

> or repeatable.

You don't need the IV to be non predictable, as long as it is a different
string every time it's all ok. The outcome of the encryption is also related
to the first block of real plaintext, so your IV can just be a few random
bytes with a decent distribution: no need for a cryptographically secure
random number generator.

~~~
almost
I'm confused, didn't the parent comment just explain why it MUST be
unpredictable? Doesn't the attack tptacek describes use the fact that the IV
is predictable?

