
GnuTLS considered harmful (2008) - calpaterson
http://www.openldap.org/lists/openldap-devel/200802/msg00072.html
======
agwa
The annoying thing about GnuTLS is that it normally might not be very widely
used, except that the Debian project initiated a huge push to make software
linkable with GnuTLS instead of OpenSSL, because of issues with the OpenSSL
license[1]. So if you're a Debian or Ubuntu user, you're probably relying on
GnuTLS a lot more than users of any other distribution, or people who compile
the upstream sources themselves. (Not that OpenSSL is a panacea, but at least
it gets more attention than GnuTLS).

[1] The OpenSSL license is incompatible with the GPL, making it technically
illegal to distribute binaries of GPL programs linked with OpenSSL (so Debian
refuses to do so), unless the GPL program has an OpenSSL license exception.

~~~
benihana
The irony of what's happening here, that dogmatism about a belief is causing
an inferior solution to be used, is infuriating and one of the reasons people
have such a problem with dogmatic personalities like rms. It's technically
illegal to use a better solution because of something as relatively
unimportant as a license. Think of it like a Maslov's hierarchy - having
strong security is _way_ more important to most people than having a proper
copyleft license. But instead of being pragmatic, we're stuck with a
ridiculously dogmatic solution that ends up harming way more than the ill it
was trying to cure.

It reminds me a lot of environmentalists going crazy to ban nuclear power in
the 70s before we had as clear a grasp on the impact of dumping carbon dioxide
into the air.

~~~
chimeracoder
> The irony of what's happening here, that dogmatism about a belief is causing
> an inferior solution to be used, is infuriating and one of the reasons
> people have such a problem with dogmatic personalities like rms. It's
> technically illegal to use a better solution because of something as
> relatively unimportant as a license.

Why do you jump to blame the GPL and rms, when one could just as easily fault
the OpenSSL authors for using the 4-clause BSD instead of the _far_ more
common 3-clause?

> It's technically illegal to use a better solution because of something as
> relatively unimportant as a license.

No, it is technically illegal to distribute compiled binaries that use
OpenSSL, because the OpenSSL authors wanted to retain the advertising
privileges. But it is not illegal to _use_ the software as long as it is
distributed in source and compiled by the end user.

I would not call licensing unimportant. As long as software is copyrightable,
licensing terms are _highly_ important.

~~~
pierrebai
The reason the GPL is annoying is that free license with an advertizing clause
have existed for a very long time and are actually widely used. A quick look
at the about box of various software will usually show you a long list of
mandatory acknowledgements for various open source licenses.

The problem is that the GPL willingly refuses to permit advertizing clauses.
Is there a congent argument about why an advertizing clause is a limitation of
freedom? The GPL is more often than other free licenses putting restirctions
on usage of diversely licensed software. It is an impediment. And, as we see,
it has real-world consequences. There is more risk for freedom using bad
software security than wielding to innocuous clauses.

~~~
chimeracoder
> The problem is that the GPL willingly refuses to permit advertizing clauses.
> Is there a congent argument about why an advertizing clause is a limitation
> of freedom

The advertising clause is not a limitation on freedom. The 4-clause BSD
license is a free software license; it just happens not to be compatible with
the GPL (not all free software licenses are).

The reasons for this are very practical: not only does it place additional
restrictions on the software (which is not permitted by the GPL), but if
multiple 4-clause BSD projects are used, each project requires its own
separate advertising statement (the 4-clause license does not permit combining
these into a single sentence):
[https://www.gnu.org/philosophy/bsd.html](https://www.gnu.org/philosophy/bsd.html)

> The reason the GPL is annoying is that free license with an advertizing
> clause have existed for a very long time and are actually widely used.

Most modern projects using permissive licenses use 3-clause BSD, MIT/X11, or
Apache, all of which are compatible with the GPL. In this day and age,
choosing a 4-clause BSD license is a fairly conscious decision to make the
project incompatible with the GPL.

~~~
hyc_symas
Choosing the 4-clause BSD license is a conscious decision to continue to
receive credit for all your hard work, when a proprietary software company
comes along and includes your code in their product. To me this is a fair
compromise for proprietary companies who refuse to open up their source code
(i.e., would never touch GPL at all).

~~~
chimeracoder
As I mention in a reply to the sibling comment, I don't fault the developer
for choosing a free software license that suits their purposes. I just don't
think it's fair to blame the _GPL_ for the incompatibility that happens when a
developer chooses a 4-clause BSD license.

(Also, remember that the developer could always dual-license - ie, "GPL or
4-clause BSD - if you want to use my software in proprietary code, then you
have to advertise me").

------
euank
It's a shame this is being upvoted so highly when it's factually incorrect. A
rebuttal can be found here: [http://nmav.gnutls.org/2011/05/is-really-gnutls-
considered-h...](http://nmav.gnutls.org/2011/05/is-really-gnutls-considered-
harmful.html)

It's rather silly that the news of a critical bug in GnuTLS that was caused by
a goto somehow makes non-news and factually wrong information from 5 years ago
popular.

~~~
mcguire
I was a bit curious about this quote:

" _It turns out that their corresponding set_subject_alt_name() API only takes
a char \_ pointer as input, without a corresponding length. As such, this API
will only work for string-form alternative names, and will typically break
with IP addresses and other alternatives. _"

Yes, an API designed for strings will break if you pass it a struct in_addr _
or something, but it should be fine with a dotted-decimal string, right?

~~~
brohee
The issue is that they designed a API taking a NUL terminated string in the
first place, as it should have been something more generic. They knew little
enough of X.509 they didn't bother to handle every cases.

My understanding of RFC 3280 is pretty old, but the relevant ASN.1 type
describing a subjectAltName seems to be :

SubjectAltName ::= GeneralNames

GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName

GeneralName ::= CHOICE { otherName [0] AnotherName, rfc822Name [1] IA5String,
dNSName [2] IA5String, x400Address [3] ORAddress, directoryName [4] Name,
ediPartyName [5] EDIPartyName, uniformResourceIdentifier [6] IA5String,
iPAddress [7] OCTET STRING, registeredID [8] OBJECT IDENTIFIER }

The IP address case is represented as an octet string, and the octet 0 is
legitimate, making their API broken...

~~~
mcguire
That's the X.509 certificate format, right? It's not a code interface.

My point was that it's not reasonable to expect an interface that appears to
be accepting a string to also accept random bytes; "10.0.0.8" isn't the same
as 0x0a000008.

------
Xylakant
Money quote from the message thread: "I can't even find the words to express
how gross this is." ([http://www.openldap.org/lists/openldap-
devel/200802/msg00100...](http://www.openldap.org/lists/openldap-
devel/200802/msg00100.html)) Interestingly, the conversation stays somewhat
civil even after that quote, looks like professionals at work :)

~~~
ajross
The quote seems to simply be complaining about the repeated use of the
subexpression "strlen(str)", by implication because it's needless and
inefficient.

Except that it's not. At least on glibc, strlen() is declared "pure" to the
compiler and (unless otherwise defeated by pointer aliasing) repeated calls
will be optimized away.

That's not to say that this is the best way to write the code, but the concern
seems poorly informed.

~~~
steveklabnik
It's not an efficiency concern, it's a security concern.

~~~
ajross
Common subexpression elimination isn't normally considered a security
technique, so I guess I don't understand your point.

Maybe you're saying it's a "code smell" kind of thing and that being sloppy
here indicates more subtle problems elsewhere? Which then hits the argument
about whether this is really "sloppy" or just intentionally simple.

Shrug. My point was just that this needs better evidence. There is no
demonstrated bug in the linked code, and the assertion that it is "gross" (OP)
or "insecure" (you) seems poorly justified.

~~~
Xylakant
The basic concern is that strlen() shouldn't be used at all on the data that's
passed to the given function since that data may be binary and not - as the
function assumes - null-terminated string. The code is "sloppy" and the
complete certificate handling seems to be sloppy. I don't want to be the judge
of that, but if you read the whole post and the ensuing thread, the argument
is made quite well and convincingly. And seriously, the last place I'd like to
see a sloppy implementation that assumes that the given data is benevolent and
does not contain a malicious payload is - guess what - a TLS library.

~~~
ambrice
There's only so much an API can do with garbage input. If this function took a
pointer and a length, that's not a magic fix, you could still pass it a bad
pointer and/or a bad length..

~~~
Xylakant
The problem here is that binary input is valid according to the spec [1]. It's
not malicious input in the sense that a programmer is using an interface
deliberately wrong but rather in the sense that a counterparty could send you
a non-garbage certificate that contains that data - which would be valid, but
still break this code. That's not comparable to passing a bad pointer or a bad
length.

[1] at least according to the post. The fact that gnutls added a binary
interface later seems to support that reading.

~~~
ambrice
Yes, the spec says the field can be string or binary. The API only handles
string fields. The API should be (and was) updated with a function that
handles binary fields, but there's nothing wrong with the original function.

If this was C++, and the function took a std::string, would you say it was
horribly broken because you serialized a 4 byte IP address into a 4 byte
std::string buffer and the function didn't handle it correctly?

~~~
Xylakant
Seriously, if the function deals with untrusted user input and pretends to
conform to a spec, weasel wording around by saying that the function does only
partially conform to the spec and will blow up in the users face when passed
other, spec compliant input and then deferring all responsibility to the user,
yes, that counts as horribly broken in my books (even though you were the one
to introduce those words). That's what we have libraries for, so that me and
you don't have to deal with this mess that x509 cert parsing is - I've seen
enough of it that I know I don't want to go down this particular hell hole -
and I've just been standing at the sideline and watching others wrestle with
it.

~~~
ambrice
functions don't conform to specs, the API and library as a whole should
conform to the spec. It's perfectly valid to have one function that supports
strings and another function that supports binary data.

~~~
leoc
Did they have such a pair of functions?

~~~
ambrice
They do now, and the first one is still using strlen(). Does the existence of
the second function mean it's now ok for the first to use strlen()? You can
still crash the program if you send binary data to the string function instead
of the binary function..

~~~
mercurial
So essentially it's an issue with C being weakly typed?

------
lispm
No matter how you look at it, C is the wrong choice for security relevant
systems software. But where is the alternative?

~~~
spiralpolitik
Actually C is an excellent choice for security relevant systems software
because the issues for developing in C are well understood and can easily be
mitigated by following 30 years worth of best practice patterns and using the
correct development tools.

The issue is developers are not using the tools or following the best
practices because they think they know better than 30 years worth of
experience or get caught up in bikeshedding about ideology, licenses and which
line the curly braces go on.

~~~
serbaut
Can you link to the 30 years of best practice document, I must have missed it.

~~~
spiralpolitik
A good place to start:

[http://www.amazon.com/The-CERT-Secure-Coding-
Standard/dp/032...](http://www.amazon.com/The-CERT-Secure-Coding-
Standard/dp/0321563212/)

Online:

[https://www.securecoding.cert.org/confluence/display/seccode...](https://www.securecoding.cert.org/confluence/display/seccode/CERT+C+Coding+Standard)

Others:

[http://www.amazon.com/Secure-Coding-Edition-Software-
Enginee...](http://www.amazon.com/Secure-Coding-Edition-Software-
Engineering/dp/0321822137/)

[http://www.amazon.com/Style-Guidelines-Programming-
Professio...](http://www.amazon.com/Style-Guidelines-Programming-Professional-
Programmers/dp/0131168983/)

[http://www.amazon.com/C-Traps-Pitfalls-Andrew-
Koenig/dp/0201...](http://www.amazon.com/C-Traps-Pitfalls-Andrew-
Koenig/dp/0201179288/)

~~~
Crito
Another good read _(it probably does not reflect how you want to write C code,
the rule about dynammic allocation is probably extreme if you are not writing
code to fly spaceships, but I think it is good to read regardless)_ :
[http://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf](http://lars-
lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf)

------
AceJohnny2
Any updates to this 6-year old post? I would hope that, with systems like
Debian forcing a move to GnuTLS from OpenSSL (for licensing reasons), it would
have since received more care.

------
blueskin_
I really don't see the Point of GnuTLS. Sure, if you want to directly
integrate OpenSSL with GPL code, you can't, but as it's a library, you should
be using it normally anyway. OpenSSL is far more widely used, has a longer
history, and I would say is better tested and understood.

------
hyc_symas
For the morbidly curious, ITS#5361 which triggered the above email:
[http://www.openldap.org/its/index.cgi/Incoming?id=5361](http://www.openldap.org/its/index.cgi/Incoming?id=5361)

~~~
hyc_symas
Other gems - ITS#5991
[http://www.openldap.org/its/index.cgi/Software%20Bugs?id=599...](http://www.openldap.org/its/index.cgi/Software%20Bugs?id=5991)
which required us to hack up a workaround. It also triggered ITS #5992
[http://www.openldap.org/its/index.cgi/Software%20Bugs?id=599...](http://www.openldap.org/its/index.cgi/Software%20Bugs?id=5992)

Discussion of the GnuTLS bug is summarized here [https://www.debian-
administration.org/users/dkg/weblog/42](https://www.debian-
administration.org/users/dkg/weblog/42)

And people still wonder that GnuTLS certificate verification bugs continue to
surface?

------
ape4
Fixing the strlen()s is easy but the binary stuff is harder. Assuming it
hasn't already been done.

~~~
hyc_symas
If you're focusing on the strlen() you're missing the forest for the trees.
The problem is someone who knew nothing about security or good programming
practices decided to write a security library and somehow convinced the
community at large to trust his code. Everyone's a beginner at some point but
no sane person trusts their system security to code written by someone so
demonstrably incompetent, and no honest beginner would attempt such an
undertaking and then advertise it as production-ready or secure.

The fact that there are still certificate validation bugs in GnuTLS today
indicates that the GnuTLS developers still haven't learned the essentials of
X.509 certificates. Even with a rapidly deployed fix for this most recent CVE,
you'd be a fool to rely on GnuTLS for anything. The code and the developers
have proven themselves not to be trustworthy. Multiple times.

