Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 04 May 2012 13:00:45 +0200
From: Ludwig Nussel <ludwig.nussel@...e.de>
To: oss-security@...ts.openwall.com
Subject: Re: CVE Request: evolution-data-server lacks SSL checking
 in its libsoup users

Marcus Meissner wrote:
> I started looking at the libsoup users, first one is evolution-data-server,
> 
> None of the libsoup users there seem to handle SSL certificate trust correctly (or at all) in my eyes.
> 
> In version 2.28 these are.
> 	Groupwise protocol handling (server/groupwise/e-gw-connection.c)
> 	Exchange protocol handling (server/exchange/lib/e2k-context.c)
> 	Google (servers/google/libgdata-google/gdata-google-service.c)
> 	calendar/backends/http/e-cal-backend-http.c
> 	calendar/backends/caldav/e-cal-backend-caldav.c
> 
> I do not fully understand the correct solution to this yet though, whether we need
> to pass in additional flags, or evaluate the "trusted" flag after the connect.

One would have thought that such abstraction libraries were invented to
make life for application programmers easier. Openssl in all it's
ugliness at least provides SSL_CTX_set_default_verify_paths(). gnutls
doesn't have an equivalent. It's utterly stupid to require each and
every application to hard code the path to a certificate bundle.
Defaulting to not doing any checks at all if the application programmer
forgot to set the magic option isn't exactly clever either.
I think we should just patch libsoup to do the checks by default against
the system certificates instead of starting to patch all it's users.
Since we do not have a certificate bundle file in older distros we'd
need to patch libsoup to use the certificate directory instead anyways.

I wonder why everyone insists in using an unmanageable bundle file
instead of the directory with individual files...

cu
Ludwig

-- 
 (o_   Ludwig Nussel
 //\
 V_/_  http://www.suse.de/
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) 

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.