Subject: Re: Working Group Last Call: Stackable Generic Security Service

From: Martin Rex <[email-masked]>
Date: Tue, 7 Nov 2006 21:00:21 +0100 (MET)

Jeffrey Altman wrote:
> 
> Please take this to the list.

I just re-sent my Emails on this to [email-masked]

> 
> Martin Rex wrote:
> > Nope, it doesn't apply to gss_release_buffer.
> > 
> > All >>output<< parameters of type gss_buffer_t are dynamically allocated
> > by the gssapi mechanism and must be passed to gss_release_buffer().
> 
> It does apply to gss_release_buffer because >>input<< buffers are
> allocated by the application and the application developer is too
> stupid to know the difference and passes the gss_buffer_t that s/he
> allocated into gss_release_buffer.

Unfortunately there is little that protects us from unexperienced
and sloppy programmers.  Even the gss-sample supplied by MIT contained
a number of serious bugs including one of these (I don't know whether
the one in the MIT distribution got fixed, I fixed my copy in
my windows SSPI wrapper gsskrb5-108.zip a while ago.

It isn't that hard to write robust and close to error-free code
in the C Language, but a lot of code that I've encountered in the
OpenSource space is brittle, buggy and uses extremely dangerous
coding style, and that includes Motif, X11, OpenSSL and MIT Kerberos.

The X11 code snipped in a recent (08-sep-06) posting is
a real pain to look at.
http://www.securityfocus.com/archive/1/445579/50/1000/threaded

A braindead approach to implement a case-insensitive string compare.
(I've seen an even worse example a few years ago)

Ask a C-programmer to implement strcasecmp/strncasecmp and you
will learn a lot about his programming skills (or the lack thereof).

If code like this (obviously broken, obvious security problem,
very small function, easy to review) is part of X11, then there
are very likely thousands of other severe problems still in there.

-Martin

_______________________________________________
Kitten mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/kitten

---

From: Jeffrey Altman <[email-masked]>
Date: Tue, 07 Nov 2006 12:18:34 -0800

> I just re-sent my Emails on this to [email-masked]

Thank you.

---

From: Martin Rex <[email-masked]>
Date: Tue, 7 Nov 2006 21:40:14 +0100 (MET)

> coding style, and that includes Motif, X11, OpenSSL and MIT Kerberos.

To be fair, this problem is *NOT* limited to OpenSource, it is
at least as bad in the proprietary code world.  My experiences
with MIT Kerberos are from around 1996 and with OpenSSL from
around 2000.

The problem with bad OpenSource code quality is that it is much
more likely giving a bad example to a larger (unskilled) audience
than closed source code.  It is much more available to Internet
search engines.  

More appropriate examples for strcasecmp/strncasecmp are likely
found in the BSD c-library or the GNU glibc, but they were
probably not changed recently, and therefore might have a
lesser chance to show up in search engines than fairly
new and broken implementations in application projects...  :-\

Sometimes the code is not really broken, just inadequate
or inefficient, and therefore giving a bad example.
E.g. mkstemp() in Cygwin32
The majority of windows filesystems are case-insensitive, but the alphabet
of filesystem-safe characters in cygwin32's mkstemp() inappropriately
includes both, the upper and the lower case characters.

A lot of base64 decoders use a
  char * ptr;
  char * b64_alphabet = "ABCDEFGHIJKLMNOPQRSTUVWXYZ
	                "abcdefghijklmnopqrstuvwxyz"
	                "0123456789+/";
  ...

  ptr = strchr(b64_alphabet, *src);
  if ( ptr!=NULL ) {
      n = ptr - b64_alphabet;

Although this code does _not_ contain an error, it should be
painfully obvious to a decent programmer that it is extremely
inefficient.

Sorry for getting way off topic.

Any Responses/comment perferably as private emails and not to the kitten list.

-Martin