Date: Tue, 5 Jan 2016 00:49:02 -0500 From: Henry Hu <henry.hu.sh@gmail.com> To: Peter Chen <peterchencs@gmail.com> Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: Nginx Vulnerability on FreeBSD Message-ID: <CAEJt7hZiXHALJGaPSua24D_djXrbjiAdfY4A3t3=KGd4Rm1rvA@mail.gmail.com> In-Reply-To: <CAHF3bU_KEYaTmeCQvkbPHPG2o=GRZXXXAYiDh4WfFeeLywroNA@mail.gmail.com> References: <CAHF3bU_KEYaTmeCQvkbPHPG2o=GRZXXXAYiDh4WfFeeLywroNA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jan 5, 2016 at 12:14 AM, Peter Chen <peterchencs@gmail.com> wrote: > Hi, > > I am trying to do a security research experiment on FreeBSD. > I try to test the Nginx Vulnerability CVE-2013-2028 on FreeBSD x86-64, with > Nginx 1.3.9/1.4.0. > (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2028) > > However, most exploit samples can succeed on Linux, but not FreeBSD. > The basic idea for the exploit, is to send a packet with a very large chunk > size, making the victim process stack-overflow. After Nginx's many crashes, > the attacker can find enough gadgets to launch a return-oriented > programming attack. > > However, it is hard to let Nginx worker process crash (due to overwritten > return address) on FreeBSD. Process crash is the first step of the whole > exploit. > > I guess (probably a wrong guess) the reason may be: the exploit needs to > set MTU to a large value. But FreeBSD seems only to allows a max MTU of > 16110. > > It is probably because of other reasons. Any comments/suggestions on this, > just to make the victim process crash? > > Here are two exploit code examples, which can run against Linux target, but > fail to make the Nginx worker process crash on FreeBSD: > > http://www.scs.stanford.edu/brop/ > http://www.scs.stanford.edu/brop/nginx-1.4.0-exp.tgz > > https://www.exploit-db.com/docs/27074.pdf > http://seclists.org/fulldisclosure/2013/Jul/att-90/ngxunlock_pl.bin > > With a simple experiment on nginx 1.4.0, it's possible that FreeBSD has more strict checks in recvfrom. For the exploit: Pwning IP 127.0.0.1 Pwning Checking for vuln... Not vuln2 >From error.log: 2016/01/05 00:43:35 [alert] 79819#0: *14 recv() failed (22: Invalid argument) while sending response to client, client: 127.0.0.1, server: localhost, request: "GET / HTTP/1.1", host: "bla.com" >From ktrace: 79819 nginx CALL recvfrom(0x3,0x801a15400,0x400,0,0,0) 79819 nginx GIO fd 3 read 104 bytes "GET / HTTP/1.1\r ... 79819 nginx CALL recvfrom(0x3,0x7fffffffcf30,0xeadbeefdeadbef03,0,0,0) 79819 nginx RET recvfrom -1 errno 22 Invalid argument >From an analysis, this should succeed: (from http://www.vnsecurity.net/research/2013/05/21/analysis-of-nginx-cve-2013-2028.html ) strace -p 11337 -s 5000 2>&1 | grep recv recvfrom(3, "GET / HTTP/1.1rnHost: 1337.vnsecurity.netrnAccept: */*rnTransfer-Encoding: chunkedrnrnfff...snip..fff0f0f0f0f", 1024, 0, NULL, NULL) = 1024 recvfrom(3, "AAA..snip..AACCCCCCCC", 18446744069667229461, 0, NULL, NULL) = 4112 > > Thanks!! > > Best, > Peter > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > -- Cheers, Henry
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAEJt7hZiXHALJGaPSua24D_djXrbjiAdfY4A3t3=KGd4Rm1rvA>