2

I have set up a server running Linux Kernel 4.4. How can I exploit this, preferably not a DoS attack? I have opened port 80(https), however I would rather do it in an elegant fashion so I can actually learn something instead of just mindlessly running slowloris. A specific vulnerability I have looked into is:

CVE-2017-18017

closed as off-topic by Conor Mancone, MechMK1, multithr3at3d, Teun Vink, Graham Hill Oct 16 at 14:43

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions asking us to break the security of a specific system for you are off-topic unless they demonstrate an understanding of the concepts involved and clearly identify a specific problem." – Conor Mancone, MechMK1, Teun Vink, Graham Hill
If this question can be reworded to fit the rules in the help center, please edit the question.

  • I'm afraid that our purpose here isn't general purpose hacking training. As a result, broad questions like this are off topic and usually get closed. You'll have better luck if you can narrow things down to a specific problem. – Conor Mancone Oct 14 at 1:41
  • Thanks for the tip. What are some sites you would recommend for questions like this? – c0mraide Oct 14 at 2:33
  • Did you mean that you serve HTTPS on port 80? That's not the normal port for HTTPS. – schroeder Oct 14 at 13:11
  • Sorry, I meant to say HTTP – c0mraide Oct 15 at 0:04
1

The description of the sechole is this:

The tcpmss_mangle_packet function in net/netfilter/xt_TCPMSS.c in the Linux kernel before 4.11, and 4.9.x before 4.9.36, allows remote attackers to cause a denial of service (use-after-free and memory corruption) or possibly have unspecified other impact by leveraging the presence of xt_TCPMSS in an iptables action.

Running a server with a 4.4 is not enough. As the kernel.org state says, the 4.4 line is still being developed, the last release is 4.4.196 from 2019-10-07. Most likely it only gets security patches, but these it gets. It is unlikely that they had not fixed it, only it is not mentioned in the CVE description.

The test the code, you need to find a kernel which is enough old for the bug to happen. I would suggest to use 4.9.35 - it is the last kernel with a clear version and mentioned in the CVE.

So we download 4.9.36 and 4.9.35, and compare their net/netfilter/xt_TCPMSS.c. You can do this also with a git command. Check, what changed.

The difference is very small:

$ diff -urNw linux-4.9.3{5,6}/net/netfilter/xt_TCPMSS.c 
--- linux-4.9.35/net/netfilter/xt_TCPMSS.c      2017-06-29 13:00:49.000000000 +0200
+++ linux-4.9.36/net/netfilter/xt_TCPMSS.c      2017-07-05 14:40:44.000000000 +0200
@@ -104,7 +104,7 @@
        tcph = (struct tcphdr *)(skb_network_header(skb) + tcphoff);
        tcp_hdrlen = tcph->doff * 4;

-       if (len < tcp_hdrlen)
+       if (len < tcp_hdrlen || tcp_hdrlen < sizeof(struct tcphdr))
                return -1;

        if (info->mss == XT_TCPMSS_CLAMP_PMTU) {
@@ -152,6 +152,10 @@
        if (len > tcp_hdrlen)
                return 0;

+       /* tcph->doff has 4 bits, do not wrap it to 0 */
+       if (tcp_hdrlen >= 15 * 4)
+               return 0;
+
        /*
         * MSS Option not found ?! add it..
         */

Note also, the ordinary networking code of the linux does not use this file. It is the MSS iptables target, thus your exploit will only work on servers using it. It should work only on data packets targeted to the TCPMSS target in the iptables.

The TCPMSS target can be used to alter the MSS (Maximum Segment Size) value of TCP SYN packets that the firewall sees. The MSS value is used to control the maximum size of packets for specific connections. Under normal circumstances, this means the size of the MTU (Maximum Transfer Unit) value, minus 40 bytes.

What we can see, is actually 2 minor changes. As it is visible, it does not make correct boundary checks for TCP packets with an uncommonly long TCP packet header length.

How exactly can be used, it is already hardcore kernel programming. You probably need to use netlink sockets on the "attacker" side, and do some debug work on the defensive one. First guarantee that the packets you send to the host, are really getting the packet (simplest way: insmod a modified xt_TCPMSS.ko which emits printk() debug log). Then you can play with it.

Probably the development of the synthetization code (on the attacker side) will be more hard.

  • Thanks! Since this specific vulnerability seems to only work for a few instances, what are some exploits you would recommend? – c0mraide Oct 14 at 2:31
  • @c0mraide Don't ask this, if your question is clearly on the attacker side, it will be closed. I formulated my answer from a security test/research view. Btw, I can't give you a code snippet what cracks that system. I only know, how could it be developed. Furthermore, anything doing significantly more than a quick freeze of the target, is much harder, particularly if it uses some tricky things, like different address space randomizations and so on. Even the freeze is hard: you need to construct bad TCP packets and send it to the target machine. The normal TCP API can create only good packets. – peterh says reinstate Monica Oct 14 at 6:22
  • Questions from the "attacker side" are allowed here. Asking how to hack things is perfectly fine. It just has to be specific. "How can I have this?" will probably get closed. "I'm trying to hack this with X, but Y and Z are a problem, whar can I do?" is usually fine. – Conor Mancone Oct 14 at 10:14
  • @ConorMancone I checked the close reason again, I agree now. – peterh says reinstate Monica Oct 14 at 10:54
  • Thanks, I will keep this in mind in the future. @ConorMancone what sites would you recommend for questions like this? – c0mraide Oct 15 at 0:06

Not the answer you're looking for? Browse other questions tagged or ask your own question.