Re: CVE-2018-17977: CentOS ipsec remote denial of service vulnerability

[luo <a4651386 () 163 com>]

Oh, sorry, maybe I didn't explain it.


I am demonstrating the remote denial of service vulnerability in the centos desktop version of the ipsec feature.Ipsec 
is currently the most widely used vpn technology, it uses ah protocol or esp protocol to encrypt or authenticate ip 
packets.


My test is divided into two parts. The first part is to open the ipsec function, which is what ah_add.c does. He didn't 
do too much, just opened a transfer mode ah protocol, ipsec is divided into ah protocol and esp Protocol, for 
simplicity, I set the encryption length to 0, which is my only non-mainstream operation.


The second part sends a special ah protocol packet, triggering the delayed release of the skb effect, causing the 
memory to be released in time, causing accumulation, and finally leading to denial of service.






The purpose of ah_add.c is just to register an IPSec encrypted channel. For simplicity, I set the encryption 
authentication length to 0.


In theory, as long as the target machine starts the ipsec function and allows ipsec message interaction with the target 
machine, it can cause the target machine to refuse service by sending a data packet.




Ah_add is just an operation that starts the ipsec service and allows the interaction with the target to be encrypted 
with a length of 0.







At 2018-10-06 00:54:06, "Solar Designer" <solar () openwall com> wrote:
> On Fri, Oct 05, 2018 at 11:46:07PM +0800, luo wrote:
> > I don't know if it is correct to publish the complete information.
>
> It is.  Linking to temporary resources like Google Drive isn't great,
> but luckily your message itself includes some detail.
>
> > > The Linux kernel 4.14.67 mishandles certain interaction among XFRM
> > > Netlink messages, IPPROTO_AH packets, and IPPROTO_IP packets, which
> > > allows local users to cause a denial of service (memory consumption
> > > and system hang) by leveraging root access to execute crafted
> > > applications, as demonstrated on CentOS 7.
>
> Since you say that "leveraging root access to execute crafted
> applications" is required, how is this a security issue?  Also, since
> this setup has to be prepared locally, how is the attack "remote"?
>
> In other words, would a sysadmin plausibly make this kind of custom
> local setup, and why?  If the answer is no, then I think there's no
> security issue here.
>
> Alexander