Source: libproxy Version: 0.4.14-2 Severity: grave Justification: user security hole Tags: security upstream Forwarded: https://github.com/libproxy/libproxy/pull/126 X-Debbugs-Cc: Debian Security Team <t...@security.debian.org>
Li Fei (@lifeibiren on Github) reported that if the server serving a PAC file sends more than 102400 bytes without a Content-Length present, libproxy can overflow its buffer by PAC_HTTP_BLOCK_SIZE (512) bytes. This PR is said to fix it, although I have not reviewed it in detail, and it would be better if someone who knows C++ better than me did the review: https://github.com/libproxy/libproxy/pull/126 Thanks to Michael Catanzaro for highlighting this as likely to be a security vulnerability during a more general conversation about libproxy. (Please reduce severity as desired if this is succesfully mitigated by some security measure - I'm assuming stack smashing is arbitrary code execution, but maybe it's just DoS.) >From source code inspection, versions >= 0.4.14-2 in stretch appear to be vulnerable. 0.4.11-4 in jessie does not appear to be vulnerable, because it assumes absence of Content-Length means a length of 0 (which is a bug, but not a security bug). Intermediate versions between jessie and stretch not checked. smcv