Home page logo

bugtraq logo Bugtraq mailing list archives

Re: [Full-disclosure] nginx exploit documentation, about a generic way to exploit Linux targets
From: Kingcope <isowarez.isowarez.isowarez () googlemail com>
Date: Fri, 26 Jul 2013 13:19:09 +0700

Thanks for the hint about how to solve the issue!
Two questions.

Is the combination of both the iptables setting and python script a standalone solution along with the exploit code or 
is it required to send the exploit 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 Internet right?



Am 24.07.2013 um 17:13 schrieb Albert Puigsech Galicia <albert () puigsech com>:

Hello everybody,

"Ioctl is needed to set the nginx socket blocking so another call to write(2) will read much more memory than it is 
possible with the default non-blocking connection of nginx."

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.

Let me to explain how we have achieved to overcome the non-blocking
socket impediment without doing so much:

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.

Let's imagine that you want to overflow a big buffer through the
network. Normally you would execute something like;

send(sock, "AAAAA….A",…);

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.

And that's what's happening on ngingx.

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.

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.

Then the application layer will get all the information in _the same_
read an the overflow will happen.

Using that TCP trick, the size limitation of the overflow is the TCP
window size instead the MTU.

One easy and **dirty** way to implement this is using iptables and
nfqueue, but there are some better ones:

# iptables -A OUTPUT -p tcp -d <IP> --destination-port <PORT> -j NFQUEUE
# python nfq.py


===/ nfq.py /===
import nfqueue
import socket
import time

data_count = 0
delayed = None

def cb(dummy, payload):
       global data_count
       global delayed
       data = payload.get_data()
# DIRTY for first data package (not three-way-handshake)
       if len(data) > 60:
               data_count += 1
               if (data_count == 1):
                       delayed = payload
                       print data
# Just DROP the packet and the local TCP stack will send it again
because won't get the ACK.
               data_count = 0

q = nfqueue.queue()
except KeyboardInterrupt:
       print "Exiting..."
===/ nfq.py /===

On 23 July 2013 19:49, king cope
<isowarez.isowarez.isowarez () googlemail com> wrote:
(see attachment)


Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Albert Puigsech Galicia
+ Mail: albert () puigsech com
+ Jabber: albert () puigsech com
+ Twitter: @apuigsech
+ Web: file:///dev/null

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]