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

[luo <a4651386 () 163 com>]

All security servers and clients need to have the IPSec function enabled, which is what ah_add does, that is to say, 
all IPSec servers or clients, if you use the desktop version of centos, there will be such a remote denial of service 
problem.


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

This is the same as what ah_add does. The only difference is that ah_add makes the encryption length 0. This makes it 
easier for me to write POC. In reality, the longer the encryption length, the more the denial of service will be.In 
other words, under the real production environment, the ipsec denial service effect will be more obvious.








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