This really belongs on dev-tech-coffee-talk :)
On 01/08/2009 07:11, Nelson Bolyard wrote:
On 2009-07-31 12:38 PDT, Ian G wrote:
On 31/07/2009 11:29, William L. Hartzell wrote:
Nelson B Bolyard wrote:
Some lax CAs will evidently issue certs with just about anything in the
DNS names. I'd pull the plug on them if I could find them, but the
presenters at Black Hat were careful NOT to reveal which CAs made the bad
certs for them. I guess that's why they call it "Black Hat".
For the record, I spent most of the day helping look at this at CAcert
(not at the code, myself, but the people).
You looked at the people? :)
Ah yes, and the people looked at the code :) Well, sort of, virtually!
It's a spread-out org, so it is all done over the net. It requires a
lot of email and chat. (I am resisting the temptation to bite the apple
and code myself...)
IMO, it would be dishonest of the Black Hat presenters to say that FF 3.0.x
is vulnerable if this flaw requires that the user trust a root CA that is
not distributed with FF 3.0.x.
Well, possibly. I also think that the presenters at BlackHat are after
bigger fish to fry, media-wise. But it is still a vulnerability at the
CA level, and I'm against any attempt to pass the blame elsewhere.
All these presenters make the same mistake of blaming SSL for a problem
that is not in the SSL protocol anywhere.
SSL itself is agnostic about certificates and CAs. SSL is used by an
application. As far as SSL is concerned, certificates are opaque blobs
of data that it transports from one peer to the other. The application, and
not SSL, decides if such a blob of data is a cert, and if it is valid or
not, and if it belongs to the desired/intended peer party or not.
If it decides that the cert passes all the tests then it gives the public
key from the cert to SSL, which then uses it because the app told it to
do so.
Of course, and you can say that, but that's mostly because it's your
area. What I've heard countless times is that this is not a CA bug
because others are responsible for presentation. But I dismiss this
because those are CA people speaking. And I'll bet that over in the
presentation / GUI area, people are grumbling about the CAs that do the
wrong thing ...
meanwhile, back to the problem :)
Applications that do SSL generally have multiple related libraries,
including an SSL library and a certificate library. NSS offers both,
among others. The faults discussed at Black Hat are certificate library
faults, not SSL library faults. No change to SSL code is necessary or
suggested to fix them.
SSL the family strongly chooses a certain way. It carries the blame for
making that choice. I've faced that way and made better choices. Back
in 1998 I did a rewrite of all my payment systems code (which in terms
understood here would look like client-cert signed-money-transactions).
The programmer convinced me at the time that "everything is moving to
x.509 and we should too." So I let him do it.
But x.509/certs/asn.1 created such a drag on everything else, for no
perceivable benefit, that in 1999 I directed it all back to straight
crypto (and OpenPGP where absolutely needed). Very annoying, costly,
but after that the code moved faster again.
SSL made that choice, and now it carries it forever.
(Yes, I'm well aware of the SSL-is-agnostic-on-certs argument. I simply
don't agree with it, it is dancing around the definitions for sake of
convenience. I'm using SSL here in the institutional, family sense.
Or, I'll have that dance when we can start using SSL-without-certs in
browsers...)
I don't know for sure, but I'll happily speculate: this is a
side-effect of complication. Using ASN1 and similar results in very
tortuous code, which contributes to all sorts of difficulties in production.
I'll agree that ASN.1 code is often tortuous code, but I wouldn't blame this
vulnerability on that.
Ever since there have been "strings" of characters handled by computers,
there have been two fundamentally different ways of organizing them.
Right. Such "labels" reach into very complicated things with lots of
shades and twists. This is another case of "when you choose ASN.1, you
get a whole train of baggage."
One way, often called "Pascal strings",...
The other method, often called "z strings"...
Nice description, I agree with the essential criticism.
... There are RFCs ...
Ah, there's a problem. You and I might be old enough to have come from
the old school, where programmers were taught the full book on this.
But we now live in a world where this is rarer. I don't say fully rare,
but 9 out of 10 programmers are not there.
So we tend to lean on tools like RFCs. And hope and prayers. But to
me, some of those tools make me happy, and some make me worried. RFCs
are in the latter class.
Evidently, for one of my sins, I was looking up the RFC on email
addresses. I spent around 30 minutes on it. I still don't "know" what
an email address is, but I did discover that spaces are ok in an email
address (!?). Oh, and that digits can't lead domain words, so whole
countries are using illegal email addresses it seems.
The problem isn't purely the fault of z string programmers. Evidently,
some CAs use software that's all Pascal strings, but they forget to check
that each and every character in each Pascal string is an allowed character
for that type of string. They should stop and reject a string with a NUL
in the middle, because NUL isn't an allowed character in the middle of DNS
names. But they forget to check that all the characters are allowed
characters, so they see a string like www.mybank.com0*.badguy.org
(where that 0 represents a NUL) and they see the asterisk, and figure
they can only check the stuff to the right of that, so they ignore every
thing to the left of it. It takes two mistakes from two different kinds
of programmers to make this vulnerability exploitable.
Right. But, most CAs use a mishmash of lots of different forms of
software. That's common in business too. You get one thing going ...
then find you need another thing. So there are borders everywhere.
Which means there are changes of languages, and changes of teams, and
changes of philosophy, and also of quality. Anecdote: it turns out
that some CSR checking I was looking at yesterday did include a NULL check:
$bits = explode(",", trim(`/usr/bin/openssl req -text -noout -in
"$CSR"|tr -d "\\0"|grep -A1 'X509v3 Subject Alternative Name:'|grep DNS:`));
CSRs are safe, but breakfast is ruined!
This is joy to the attacker. I first learnt this in the army, where
they taught me to figure out where the enemy's units were, and which
maps they used. Then, attack between the units or where the maps cross
over.
One can say "they should write good code" but that's just hopeful. To
echo Dan, to fix this we should really start again using techniques
developed more in more modern times. But that's equally hopeful :)
Has someone invented another string representation that is neither zstring
nor pascal?
I have not heard of one.
Has someone found a way to ensure that programmers don't forget
to check for disallowed characters in strings?
I believe so. It's called OO. This came to prominance in the 80s.
Combined with a bunch of other stuff, it allows the encapsulation of all
string issues. Including checking, comparison, debug-printing,
random-generation, and most importantly, easy unit testing. The code
for a string is quite a big program, but this means that others are simple.
In my direct experience, I've been able to translate code based on this
in a weekend from one language to another (SDP1, Java to PHP as it
happens). That's the whole lot from byte level up to encrypting and
decrypting packets, and getting it right, solid and reliable, because it
does all the self-testing and comparison testing by random generation.
I grant that it is a pig to implement in C. That took more like 10
days. Because of the memory allocation problem. There are right ways
(pass in statics / stack) and then there are wrong ways (malloc). I
don't think the book is yet complete on how to do OO in C... But once
done, the rest of the C code moves along faster and more reliably.
Time for more coffee :)
iang
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
