It appears my Ubuntu server only updates nginx mainline to 1.5.11. I've disabled spdy support in my listen directive for now as an easier work around.
It's not affected on Debian/Ubuntu, check --with-debug flag.
Thank you.
Nginx SPDY heap buffer overflow (affects 1.3.15 – 1.5.11)
21–30 of 32 posts
Re: Nginx SPDY heap buffer overflow (affects 1.3.15 – 1.5.11)
#22Earlier quoted context omitted.
It's not affected on Debian/Ubuntu, check --with-debug flag.
Thank you.
btw, I use packages from nginx.org, they're updated in time with every release: http://nginx.org/en/linux_packages.html
Re: Nginx SPDY heap buffer overflow (affects 1.3.15 – 1.5.11)
#23Before you panic: "The problem affects nginx 1.3.15 - 1.5.11, compiled with the ngx_http_spdy_module module (which is not compiled by default) and without --with-debug configure option, if the "spdy" option of the "listen" directive is used in a configuration file."
Well, SPDY is enabled by default on 1.5.11 from what I understand, so they better push out 1.5.12 out (at least not seeing it yet)
Re: Nginx SPDY heap buffer overflow (affects 1.3.15 – 1.5.11)
#24Why was it replaced with "#if 1" instead of just deleting the entire "if/end" delimiters? Won't that always evaluate to true?
Maybe they wanted a patch that could be easily applied to older versions. It might have an elif later too, although I'm guessing that's not too common after debug blocks.
Re: Nginx SPDY heap buffer overflow (affects 1.3.15 – 1.5.11)
#25Re: Nginx SPDY heap buffer overflow (affects 1.3.15 – 1.5.11)
#26 - if (ngx_list_init(&r->headers_in.headers, r->pool, sc->entries + 3,
+ if (ngx_list_init(&r->headers_in.headers, r->pool, 20,
Re: Nginx SPDY heap buffer overflow (affects 1.3.15 – 1.5.11)
#27Earlier quoted context omitted.
btw, I use packages from nginx.org, they're updated in time with every release: http://nginx.org/en/linux_packages.html
Do the upstream packages still use a different configuration path from the Debian/Ubuntu packages?
Yes. There's no sites-available or sites-enabled, and some configuration is split off into different files in the conf.d directory.
Re: Nginx SPDY heap buffer overflow (affects 1.3.15 – 1.5.11)
#28Patch is pretty interesting. Why was buffer overflow protection behind a debug flag? http://nginx.org/download/patch.2014.spdy2.txt
Without context (I'm not familiar with nginx' code) the blatant subtraction of pointers was scary, too.
As everyone is of course no doubt aware, subtraction of pointers is only valid in C if you can guarantee that the pointers point to the same "object" (or at most 1 character past the end of an object).
I would prefer an interface using a size_t count of available space, rather than passing an end-pointer around.
Again, this is based solely on reading the patch, so it might be perfectly fine. Considering nginx' reputation, I guess it's academic.
Re: Nginx SPDY heap buffer overflow (affects 1.3.15 – 1.5.11)
#29Patch is pretty interesting. Why was buffer overflow protection behind a debug flag? http://nginx.org/download/patch.2014.spdy2.txt
Without context (I'm not familiar with nginx' code) the blatant subtraction of pointers was scary, too. As everyone is of course no doubt aware, subtraction of pointers is only valid in C if you can guarantee that the pointers point to the same "object" (or at most 1 character past the end of an object). I would prefer an interface using a size_t count of available space, rather than passing an end-pointer around. Ag…
It's a common practice to use two pointers when parsing some stream data buffer. If you will use a pointer to the start of the buffer and the size of an available data to parse, then you would need to change two variables instead of one on every parsing stage. So you have more opportunity to make a mistake.
Re: Nginx SPDY heap buffer overflow (affects 1.3.15 – 1.5.11)
#30Patch is pretty interesting. Why was buffer overflow protection behind a debug flag? http://nginx.org/download/patch.2014.spdy2.txt
Without context (I'm not familiar with nginx' code) the blatant subtraction of pointers was scary, too. As everyone is of course no doubt aware, subtraction of pointers is only valid in C if you can guarantee that the pointers point to the same "object" (or at most 1 character past the end of an object). I would prefer an interface using a size_t count of available space, rather than passing an end-pointer around. Ag…
It's kind of implied by the parameters that they point to the same object; they're named "pos" and "end" after all. But I agree, a count variable is nicer.
The subtraction also has a (very theoretical) problem that its result must fit in ptrdiff_t (signed), and it would produce undefined behavior when you have a huge object whose size doesn't fit in ptrdiff_t (but does in size_t, by definition).