
Security vulnerability found in Nginx - dirtyaura
http://mailman.nginx.org/pipermail/nginx-announce/2012/000076.html
======
uggedal
Arch Linux already has the 1.0.14 release available in the community repo[1].

There are still no new patch level version of 0.7.67 available for Debian
Squeeze[2] or Ubutu 10.4 LTS' 0.7.65 version[3]. EPEL for RHEL and derivatives
also lack a new upstream version[4].

[1]:
[http://projects.archlinux.org/svntogit/community.git/commit/...](http://projects.archlinux.org/svntogit/community.git/commit/trunk?h=packages/nginx&id=9fa938f3189c65b4d4e30d6f82868f59b8dce503)

[2]:
[http://packages.debian.org/changelogs/pool/main/n/nginx/?C=M...](http://packages.debian.org/changelogs/pool/main/n/nginx/?C=M;O=D)

[3]:
[http://changelogs.ubuntu.com/changelogs/pool/universe/n/ngin...](http://changelogs.ubuntu.com/changelogs/pool/universe/n/nginx/?C=M;O=D)

[4]:
[http://dl.fedoraproject.org/pub/epel/6/x86_64/repoview/nginx...](http://dl.fedoraproject.org/pub/epel/6/x86_64/repoview/nginx.html)

~~~
IgorPartola
Re [Debian/Ubuntu], wait, they incorporated the fix on 17 June 2011, but the
patch is being exposed now on the nginx mailing list?

Edit: changed [2] to [Debian/Ubuntu]

~~~
uggedal
The vulnerability from last year sounded similar and I therefore initialy
mixed them. Updated my comment.

------
matthavener
I may be misinterpreting the patch, but it seems like this is a NULL byte
injection vulnerability, all stemming from '\0' termination in C-strings. I
wonder if length-buffer pairs are more practical when security is a
consideration?

Similar issues in Perl:
[http://www.phrack.org/issues.html?issue=55&id=7#article](http://www.phrack.org/issues.html?issue=55&id=7#article)
and other languages:
[http://hakipedia.com/index.php/Poison_Null_Byte#Perl_PHP_Nul...](http://hakipedia.com/index.php/Poison_Null_Byte#Perl_PHP_Null_Byte_Injection)

~~~
wladimir
IMO, zero-terminated strings are, and always have been, a bad idea.
Discriminating against a certain character instead of just regarding it as
opaque blob of data will bite you in unexpected ways, and strlen() taking O(N)
is another drawback.

The string functions in the C standard library suck. bstring is a better
alternative:
[http://bstring.cvs.sourceforge.net/viewvc/bstring/tree/bstrl...](http://bstring.cvs.sourceforge.net/viewvc/bstring/tree/bstrlib.txt?pathrev=HEAD)
. Glib also has a good string library...

~~~
kbolino
Something to bear in mind regarding non-standard string libraries: syscalls
(like open[1] on POSIX or CreateFile[2] on Windows) use null-terminated
strings, which means that you have to be careful about embedded nulls, no
matter what library you use, when a string gets passed to a syscall somewhere
in the chain.

[1]
[http://pubs.opengroup.org/onlinepubs/000095399/functions/ope...](http://pubs.opengroup.org/onlinepubs/000095399/functions/open.html)
[2] [http://msdn.microsoft.com/en-
us/library/windows/desktop/aa36...](http://msdn.microsoft.com/en-
us/library/windows/desktop/aa363858%28v=vs.85%29.aspx)

~~~
barrkel
It may be interesting to note that Windows syscalls (i.e. to the NT kernel
rather than the Win32 layer wrappers like CreateFile) do not actually use
null-terminated strings - they use UNICODE_STRING[1], which is a structure
containing a 16-bit length, 16-bit buffer length, and pointer to a buffer of
2-byte characters.

NtCreateFile[2] (and the kernel-side implementation of ZwCreateFile[3]) take a
file name in the form of OBJECT_ATTRIBUTES, whose ObjectName field is of type
PUNICODE_STRING. CreateFile is implemented in terms of NtCreateFile;
CreateFile enforces Win32 semantics like case insensitivity that NtCreateFile
does not; POSIX semantics can be implemented on top of NtCreateFile, but not
easily with CreateFile.

[1] [http://msdn.microsoft.com/en-
us/library/windows/hardware/ff5...](http://msdn.microsoft.com/en-
us/library/windows/hardware/ff564879%28v=vs.85%29.aspx)

[2] [http://msdn.microsoft.com/en-
us/library/bb432380%28v=vs.85%2...](http://msdn.microsoft.com/en-
us/library/bb432380%28v=vs.85%29.aspx)

[3] [http://msdn.microsoft.com/en-
us/library/windows/hardware/ff5...](http://msdn.microsoft.com/en-
us/library/windows/hardware/ff566424%28v=vs.85%29.aspx)

------
tptacek
This is a very bad bug, and you should fix it ASAP. Don't wait.

~~~
spindritf
What are the possible implications?

~~~
tptacek
You can safely trust me on this. Also, if you're concerned, the patch is very
straightforward, minimal, safe, and fairly unintrusive. It's not going to
break anything.

Just patch it.

~~~
IgorPartola
Hopefully Red Hat, Debian, FreeBSD, etc. maintainers are reading this.

~~~
logic
Red Hat Bugzilla is tracking this for both RHEL (EPEL) and Fedora:

Master tracking bug: <https://bugzilla.redhat.com/show_bug.cgi?id=803856>

EPEL: <https://bugzilla.redhat.com/show_bug.cgi?id=803859>

Fedora: <https://bugzilla.redhat.com/show_bug.cgi?id=803858>

RPMs for 1.0.14 are available in koji at those second two links, or you can
grab it via "yum --enablerepo=updates-testing update nginx" once the mirrors
all pick it up.

------
rdl
This is particularly interesting because in a lot of deployments, nginx sits
out in front of a lot of other stuff as a load balancer, where it is nicely
exposed.

You REALLY should be using multiple boxes if you're running load balancers
(especially sw load balancers) with some kind of heartbeat failover. That way
you can upgrade single boxes easily, and are ok in case one of them dies. With
a bug of this severity, you won't have time to test the patch, so it's
probably best to upgrade one at a time in production.

Remember, even if you're running Apache or something else for your actual web
server, you can easily have something like nginx sitting in front as a
proxy/load balancer. Often in front of your security monitoring devices... and
you may have forgotten about it.

------
aaronblohowiak
This only matters if your backend is going to set a header that contains a
null byte. Since some people echo back user data in headers (ugh) this could
cause an issue. Rails is more than happy to let you put NULLs in response
headers, btw. Of course, all of the ASCII CTL characters (0..27) are forbidden
by the spec: <http://www.ietf.org/rfc/rfc2068.txt>

------
jaryd
Hey guys,

Looking for a consensus on the most stable way to update nginx installations
from source.

Thanks!

~~~
krobertson
I prefer to custom build deb packages (on Ubuntu myself) using a project
called brew2deb:

<https://github.com/tmm1/brew2deb>

It provides a DSL for describing how to build and package something, including
patching, and already has a nginx formula:

[https://github.com/tmm1/brew2deb/blob/master/packages/nginx/...](https://github.com/tmm1/brew2deb/blob/master/packages/nginx/formula.rb)

Will likely be adding in this patch today...

~~~
ef4
I second the idea of building your own deb.

But if you're going to learn a DSL for building debs, why not just learn how
to build debs? Your distro already provides the necessary build formula, along
with well-integrated startup scripts, etc.

To start out, just build as given:

    
    
        apt-get build-dep nginx
        apt-get source nginx
        cd nginx-$VERSION
        dpkg-buildpackage
    

Then to customize, go into the source tree and update whatever you want to
update, and rebuild. You'll see there's already a debian/patches directory
where you can drop patches to apply automatically.

I tend to just keep the "debian" directory in source control, so I can take a
fresh upstream tarball, check out my debian rules into it, and kick off the
build.

~~~
krobertson
I've done custom debian packages from scratch and always found it a pain. I've
also done customized source builds and still prefer this approach because its
simple, slimmer, easily version controlled, and wrapped up in a single
command.

But there are many ways to fry an egg. I prefer this way, but overall having a
package is a big plus for commonality between systems and convenience vs
simply building from source.

------
digitalsushi
The ides of march bug.

