Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 293785 - <www-servers/nginx-{0.7.64,0.8.23}: TLS renegotiation vulnerability (CVE-2009-3555)
Summary: <www-servers/nginx-{0.7.64,0.8.23}: TLS renegotiation vulnerability (CVE-2009...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo Security
URL: http://sysoev.ru/nginx/patch.cve-2009...
Whiteboard: B3 [glsa]
Keywords:
Depends on:
Blocks: CVE-2009-3555 CVE-2009-3896 CVE-2009-3898
  Show dependency tree
 
Reported: 2009-11-20 01:05 UTC by Stefan Behte (RETIRED)
Modified: 2012-03-28 10:59 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
patch for 0.7.64 ebuild (nginx-0.7.64.patch,831 bytes, patch)
2009-11-23 23:32 UTC, Rudy Grigar (RETIRED)
no flags Details | Diff
Fixes compile failure where USE="-ssl" (nginx-0.7.64-no-ssl-compile-fix.patch,819 bytes, patch)
2009-12-30 14:02 UTC, kfm
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan Behte (RETIRED) gentoo-dev Security 2009-11-20 01:05:51 UTC
"An updated patch to fix a renegotiation vulnerability in SSL protocol in 0.1.0-0.8.22. The patch is not required for versions 0.8.23+ and 0.7.64+."

Please bump or provide an patched ebuild.
Comment 1 Stefan Behte (RETIRED) gentoo-dev Security 2009-11-20 01:14:50 UTC
Sorry for bugspam.
Comment 2 Rudy Grigar (RETIRED) gentoo-dev 2009-11-23 23:32:41 UTC
Created attachment 211024 [details, diff]
patch for 0.7.64 ebuild

This is a small change for 0.7.64 that enables the realip module by default, not depending on the fastcgi use flag.  This module is useful for any configuration that needs to read the realip from X-Real-IP or X-Forwarded-For headers (i.e. Varnish->Nginx).
Comment 3 Pavel Labushev 2009-11-24 04:29:51 UTC
According to nginx' author, "--with-md5=/usr/include" and "--with-sha1=/usr/include" must be removed from args or changed to point to the source code of the libs that implement md5 and sha1.
Comment 4 Pavel Labushev 2009-12-03 16:00:30 UTC
What's the reason for delaying the ebuild so long? 0.7.64 is a stable release that contains a security fix, and it should be treated accordingly.
Comment 5 Dirkjan Ochtman (RETIRED) gentoo-dev 2009-12-08 14:54:51 UTC
I've put 0.7.64 and 0.8.29 in the unstable trees.
Comment 6 Stefan Behte (RETIRED) gentoo-dev Security 2009-12-18 15:34:30 UTC
Arches, please test and mark stable:
=www-servers/nginx-0.7.64
=www-servers/nginx-0.8.29
Target keywords : "amd64 x86"

Comment 7 Christian Faulhammer (RETIRED) gentoo-dev 2009-12-27 15:11:47 UTC
(In reply to comment #5)
> I've put 0.7.64 and 0.8.29 in the unstable trees.

 No regression, but have a look at bug 241756.

By the way, I will only mark the 0.7* series stable for x86, if you disagree cry now or readd us.
Comment 8 Christian Faulhammer (RETIRED) gentoo-dev 2009-12-27 15:42:10 UTC
And it fails without USE=ssl 

In file included from src/http/ngx_http_file_cache.c:10:
src/core/ngx_md5.h:18:17: error: md5.h: No such file or directory
In file included from src/http/ngx_http_file_cache.c:10:
src/core/ngx_md5.h:22: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ngx_md5_t’
src/http/ngx_http_file_cache.c: In function ‘ngx_http_file_cache_create_key’:
src/http/ngx_http_file_cache.c:144: error: ‘ngx_md5_t’ undeclared (first use in this function)
src/http/ngx_http_file_cache.c:144: error: (Each undeclared identifier is reported only once
src/http/ngx_http_file_cache.c:144: error: for each function it appears in.)
src/http/ngx_http_file_cache.c:144: error: expected ‘;’ before ‘md5’
src/http/ngx_http_file_cache.c:152: error: ‘md5’ undeclared (first use in this function)
make[1]: *** [objs/src/http/ngx_http_file_cache.o] Error 1
make[1]: *** Waiting for unfinished jobs....
make[1]: Leaving directory `/var/tmp/portage/www-servers/nginx-0.7.64/work/nginx-0.7.64'
make: *** [build] Error 2
Comment 9 kfm 2009-12-30 13:58:30 UTC
Firstly, I think openssl should be declared as a mandatory dep, because its md5 implementation is required, irrespective of the intended role of the ssl USE flag. Secondly, the reason it breaks appears to be due to the use of --with-md5-asm and --with-sha1-asm, as already alluded to by Pavel in Comment 3. To quote Igor Sysoev himself:

"You do not need --with-openssl=/usr/lib --with-md5=/usr/lib. They are required only if you want to build OpenSSL or libmd5 from sources, but not if you want to use already built libraries. In the later case nginx will find them by itself, or if they are in non-standard place, you should help it by: --with-cc-opt="-I /path/to/headers --with-ld-opt="-L /path/to/libraries"

Source: http://nginx.org/pipermail/nginx/2009-April/011066.html

I removed the aformentioned configure options and tried a build with USE="-ssl" and found that it was able to compile successfully with md5 support in working order:

-------------------------------------------------
checking for OpenSSL md5 crypto library ... found

...

Configuration summary
   + OpenSSL library is not used
   + md5: using system crypto library
-------------------------------------------------

As a side note, sha1 support wasn't detected but I don't believe it matters. I checked the sources and nothing yet uses it, whereas the md5 routines are used in "ngx_http_file_cache.c" and "ngx_http_secure_link_module.c". Igor has spoken in the past of using sha1 in a mysql module but it is nowhere to be seen (see http://permalink.gmane.org/gmane.comp.web.nginx.english/305).
Comment 10 kfm 2009-12-30 14:02:54 UTC
Created attachment 214621 [details, diff]
Fixes compile failure where USE="-ssl"

This patch applies against the existing 0.7.64 ebuild.
Comment 11 kfm 2009-12-30 14:08:27 UTC
Apologies for posting again, but I feel that it is important that I correct myself. Where I wrote "... reason it breaks appears to be due to the use of
--with-md5-asm and --with-sha1-asm", I had actually intended to write: "... reason it breaks appears to be due to the use of --with-md5 and --with-sha1".
Comment 12 Dirkjan Ochtman (RETIRED) gentoo-dev 2009-12-30 15:05:14 UTC
In http://n2.nabble.com/Dependencies-td3865386.html, Igor writes "nginx can be built without any external library. nginx may use zlib (gzip), PCRE (regexes), and md5 (cache), however, you disable these features. Also, nginx may use OpenSSL, libxslt, libperl, libGD, GeoIP, and Google perftools." so I don't see why we should require the OpenSSL dependency? Also, why does our package depend on perl unconditionally? That seems wrong.
Comment 13 Christian Faulhammer (RETIRED) gentoo-dev 2009-12-30 15:10:47 UTC
This is a security bug, reopen.
Comment 14 kfm 2009-12-31 02:16:50 UTC
Re Comment 12, surely it should be obvious. You need MD5 support unless you have a plan to start building nginx with "--without-http-cache". I pointed out before that its required in ngx_http_file_cache.c and that's why Igor says "may use ... md5 (cache)" (emphasis on may). If you don't want to use md5, the cache has to go and presumably that's not on the agenda. Have actually looked at the build error that Christain is complaining about?

In file included from src/http/ngx_http_file_cache.c:10:
src/core/ngx_md5.h:18:17: error: md5.h: No such file or directory
In file included from src/http/ngx_http_file_cache.c:10:
src/core/ngx_md5.h:22: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'ngx_md5_t'
src/http/ngx_http_file_cache.c: In function 'ngx_http_file_cache_create_key':
src/http/ngx_http_file_cache.c:129: error: 'ngx_md5_t' undeclared (first use in this function)
src/http/ngx_http_file_cache.c:129: error: (Each undeclared identifier is reported only once
src/http/ngx_http_file_cache.c:129: error: for each function it appears in.)
src/http/ngx_http_file_cache.c:129: error: expected ';' before 'md5'
src/http/ngx_http_file_cache.c:137: error: 'md5' undeclared (first use in this function)
make[1]: *** [objs/src/http/ngx_http_file_cache.o] Error 1
make[1]: *** Waiting for unfinished jobs....
make[1]: Leaving directory `/var/tmp/portage/www-servers/nginx-0.7.62/work/nginx-0.7.62'
make: *** [build] Error 2

As I said also, it's require by "ngx_http_secure_link_module.c" but, as far as I can tell, that isn't enabled by default - not unless "--with-http_secure_link_module" is passed to ./configure.

So I maintain that openssl should indeed be a fixed dep, unless you intend to expose more configure choices to the end-user, or unless you intend to start turning off these features mandatorily.

Just to get back to the original point as well, --with-md5 should not be invoked with a directory as a parameter, unless that directory contains sources (which it does not). As already demonstrated, it need not be invoked at all and sha1 support isn't actually used in the nginx codebase (yet).
Comment 15 kfm 2009-12-31 02:20:56 UTC
Also, regarding perl, I really don't know why it's in the ebuild as a fixed dep. Maybe it's a mistake, or maybe nginx fails to build without it regardless of whether --with-http_perl_module is used or not? 
Comment 16 kfm 2009-12-31 04:25:27 UTC
Examples from the NetBSD and FreeBSD ports re-inforcing Igor's remarks that --with-cc-opt and --with-ld-opt are the appropriate options to use if there is a wish to explicitly reference required external headers (including those of OpenSSL):

NetBSD:

  CONFIGURE_ARGS+= --with-ld-opt=-L${PREFIX}/lib\ -Wl,-R${PREFIX}/lib

FreeBSD:

  CONFIGURE_ARGS+=--prefix=${ETCDIR} \
                  --with-cc-opt="-I ${LOCALBASE}/include" \
                  --with-ld-opt="-L ${LOCALBASE}/lib" \

Neither of them use *any* of the following: --with-pcre, --with-md5, --with-sha1, --with-zlib, --with-openssl (i.e. all the options which are designed to be invoked so that they point to a directory containing the *sources* of the relevant library).

I suppose the most correct thing to do might be to invoke --with-cc-opt and --with-ld-opt to refer to "${ROOT}/lib" in the case of Gentoo but, if not otherwise instructed, the build system will look for headers under /usr/lib and find them.
Comment 17 kfm 2009-12-31 04:36:31 UTC
Correction: refer to "${ROOT}/include" and "${ROOT}/lib" respectively, and the headers would be found under /usr/include of course. Anyway, I'll stop spamming - I've said all that needs to be said.
Comment 18 Dirkjan Ochtman (RETIRED) gentoo-dev 2009-12-31 15:50:17 UTC
Thanks for your elaborate investigation! Sorry if I'm being dense, I'm just trying to figure this out before I commit something stupid.

So:
- the basic server doesn't need ssl
- the cache module needs an md5 routine
- gentoo always includes the cache module
- the md5 routine is grabbed from openssl in gentoo

Correct? So I'm unsure about this:

"md5: using system crypto library"

It would appear to me that the system crypto library is something other than openssl. You quote Igor as stating "nginx may use zlib (gzip), PCRE (regexes),
and md5 (cache), however, you disable these features. Also, nginx may use
OpenSSL, libxslt, libperl, libGD, GeoIP, and Google perftools", which seems to imply that md5 != openssl, so that's what lead me to wonder if we do need openssl.

Also, why did you remove the --with-*-asm flags? I'm not seeing any need for this based on any of your comments, I think. (Thanks again for answering my questions.)
Comment 19 kfm 2009-12-31 16:48:08 UTC
Re: Comment 18 ...

>>> - the basic server doesn't need ssl

Correct.

>>> - the cache module needs an md5 routine

Yes, and the secure link module. Otherwise you will encounter the 
following error: 

./configure: error: the HTTP cache module requires md5 functions from 
OpenSSL library. You can either disable the module by using 
--without-http-cache option, or install the OpenSSL library into the 
system, or build the OpenSSL library statically from the source with 
nginx by using --with-http_ssl_module --with-openssl=<path> options. 

>>> - gentoo always includes the cache module

Yes. You can determine this based on two things:

1) if you run ./configure --help | grep http-cache within the nginx 
   sources the only option to be seen is --without-http-cache (indicating 
   that it is compiled in by default)
   
2) the ebuild is not specifying --without-http-cache ;)

Using the same method, you can determine that http_secure_link_module is 
not built in by default. 

>>> - the md5 routine is grabbed from openssl in gentoo 

Yes, but not just in gentoo. nginx expects to use openssl to that end in 
any situation. It's stated plainly by the error message I reproduced 
above. And there is the option of passing compiler/linker options to 
ensure that it is found. 

>>> It would appear to me that the system crypto library is something 
>>> other than openssl. 

No, it's definitely openssl. Aside from what has already been discussed, 
try renaming /usr/include/openssl to something else then running 
./configure. It will fail ... unless you pass --without-http-cache. 

As for the other dependencies, it obviously boils down to how we choose 
to configure nginx and/or how we let the user control that process. As 
far as I can tell, most of these relationships can be determined simply 
by studying the configure --help text alone. 

>>> Also, why did you remove the --with-*-asm flags? I'm not seeing any 
>>> need for this based on any of your comments, I think. (Thanks again 
>>> for answering my questions.) 

That's a good question. The fact is I hadn't made a conscious decision 
to remove them and as I started to write this sentence, I realised that 
I had no idea as to the actual ramfications! So, one brief investigation 
later, I think I now understand. When compiling OpenSSL itself, the 
MD5_ASM and/or SHA1_ASM environment variables may be defined so as to 
use some x86 optimised assembler routines. Interestingly, the routines 
in questions are encapsulated in perl (see "crypto/md5/asm/md5-586.pl" 
and "crypto/md5/asm/md5-x86_64.pl" in the OpenSSL sources). Further, it 
can be seen in nginx's "auto/lib/md5/make" file that it will define 
MD5_ASM if building the OpenSSL sources (the relation to --with-md5-asm 
can be seen in the "auto/options"). 

So, my tentative conclusion is as follows: if --with-md5-asm is defined 
AND if nginx is instructed to build openssl itself by way of pointing it 
to a valid source tree using --with-md5 (*), it will add -DMD5-ASM to 
CFLAGS when building OpenSSL. 

But we don't want to do that, do we? We just want to link in the openssl 
library that's already provided by the distro, just like the BSDs are 
doing. If openssl is to be optimised in any way, that should be a matter 
for the openssl ebuild itself. Therefore, I think my original patch is 
actually right. Specifying --with-md5-asm should be superfluous if we 
are linking in the system-provided library, as nginx is not taking any 
responsibility for building any OpenSSL code (nor does it even have 
access to the sources). 

For safety's sake, we should probably drop the two lines as per the 
patch, but instead add the following as per Igor's comment and the BSDs: 

  --with-cc-opt="-I${ROOT}/include" \
  --with-ld-opt="-L${ROOT}/lib"

I'm guessing that will help portage do the right thing under unusual 
conditions - are there any conditions where $ROOT would not "/"? Anyway, 
I'll leave that question to you developers. In my testing, it works with 
or without. 

---

(*) The very configure option which we are currently misusing and which 
is leading to the compile failure under discussion. The correct way to 
use it would be --with-md5=/path/to/openssl/sources.
Comment 20 kfm 2009-12-31 16:57:13 UTC
My apologies. When discussing the compiler/linker options, I should have wrote:

  --with-cc-opt="-I${ROOT}/usr/include" \
  --with-ld-opt="-L${ROOT}/usr/lib"

Just for kicks, I added these and tried passing deliberately incorrect paths to see if it would affect the build. Turns out that it doesn't, so unless there are any legitimate circumstances under which ${ROOT} would not be "/" and where we wouldn't be able to include openssl from the normal paths, I suppose we needn't bother.
Comment 21 Dirkjan Ochtman (RETIRED) gentoo-dev 2010-01-01 20:35:20 UTC
Committed new revisions of 0.7.64 and 0.8.29.

Kerin, would you be interested in becoming a gentoo dev, by any means?
Comment 22 Christian Faulhammer (RETIRED) gentoo-dev 2010-01-02 14:01:24 UTC
stable x86
Comment 23 Dirkjan Ochtman (RETIRED) gentoo-dev 2010-01-03 10:47:34 UTC
Christian: I don't think we want to have a stable 0.8.x yet. Upstream has considered 0.8.x unstable so far, and we haven't previously had a stable 0.8 yet, as far as I can see.
Comment 24 kfm 2010-01-03 11:14:09 UTC
Re: Comment 23 - Indeed. Why, even Arch Linux are sticking to 0.7.64, a distro whose motto appears to be "if upstream so much as twitches, pounce with all the ferocity of a rabid leopard!"

Re: Comment 21 - Thanks, but I don't think I could consistently cope with the duties/responsibilities (i.e. work) that would be entailed, and I don't identify with the culture anymore to the extent that I would have any notion as to where I would fit in. I just (contribute to|complain about) things that I use or am interested in from time to time, energy permitting, and don't encounter any impedance that can be attributed alone to my not being among the developer cognoscenti, most of the time. That's also a very subtle way of saying that the things I would like to change are not things that I think I could possibly change anyway.

I'm going to be a cheeky monkey now and ask amd64 to hurry along with the stabilisation for 0.7.64 ... thanks!
Comment 25 Markus Meier gentoo-dev 2010-02-01 19:41:39 UTC
amd64 stable, all arches done.
Comment 26 Dirkjan Ochtman (RETIRED) gentoo-dev 2010-02-02 11:10:40 UTC
I think this can be closed now.
Comment 27 Stefan Behte (RETIRED) gentoo-dev Security 2010-02-06 15:49:12 UTC
No it can't.
Please see: http://www.gentoo.org/security/en/vulnerability-policy.xml

Ready to vote, I vote YES (together with the other nginx stuff).
Comment 28 Alex Legler (RETIRED) archtester gentoo-dev Security 2010-03-04 11:55:05 UTC
YES too, added to request.
Comment 29 Benedikt Böhm (RETIRED) gentoo-dev 2010-05-30 07:17:21 UTC
glsa anyone?
Comment 30 GLSAMaker/CVETool Bot gentoo-dev 2012-03-28 10:59:22 UTC
This issue was resolved and addressed in
 GLSA 201203-22 at http://security.gentoo.org/glsa/glsa-201203-22.xml
by GLSA coordinator Sean Amoss (ackle).