linux exploit

17 views
Skip to first unread message

Howard White

unread,
May 13, 2019, 9:33:47 AM5/13/19
to nlug...@googlegroups.com

Tilghman Lesher

unread,
May 13, 2019, 9:09:35 PM5/13/19
to NLUG
It is, indeed, bleeding edge, but the SecurityFocus article makes
clear that this is a bug that goes back to even Linux 2.0 kernels. So
you're vulnerable, period, at least until your upstream vendor
publishes an updated kernel that corrects this race condition.
> --
> --
> You received this message because you are subscribed to the Google Groups "NLUG" group.
> To post to this group, send email to nlug...@googlegroups.com
> To unsubscribe from this group, send email to nlug-talk+...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/nlug-talk?hl=en
>
> ---
> You received this message because you are subscribed to the Google Groups "NLUG" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to nlug-talk+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/nlug-talk/5ae0666c-e09a-5d14-b5ae-c5ee3c75ff19%40vcch.com.
> For more options, visit https://groups.google.com/d/optout.



--
Tilghman

Tilghman Lesher

unread,
May 13, 2019, 9:33:23 PM5/13/19
to NLUG
Reading on this a little bit more, it looks like this bug would be
extremely difficult to exploit. Basically, it only occurs when you
allocate a socket, attempt to connect to a remote machine, and the
attempted connection fails. If that happens, you get a use-after-free
condition.

Given how frequent the described condition occurs, I have to question
whether SecurityFocus was accurate in implicating kernels back to 2.0.
I would suspect that this might be applicable only to 5.0 kernels, but
I don't have any evidence to suggest either way.

I'd also question whether it was accurate in describing this as a
remote exploit, since this describes a connection FROM the affected
machine, not TO it. You don't use connect() on incoming TCP
connections; you use listen() and accept() for that. However, it is
also true that some well-known services use combinations like this.
FTP, in particular, comes to mind, at least in active (default) mode.
So potentially, an attacker might initiate an FTP connection to a
vulnerable machine, then refuse attempted connections for FTP-DATA.

You see why I think this might not implicate earlier kernels? That
happens all the time, if you're behind a firewall and don't have the
passive FTP option turned on. And yet, that doesn't generally crash
Linux machines.
--
Tilghman

Howard White

unread,
May 13, 2019, 9:41:59 PM5/13/19
to nlug...@googlegroups.com
Thank you, Tilghman. I did not read the source documents due to lack of
detail knowledge. We cannot be too careful but I often wonder about
sensationalism.

Howard
Reply all
Reply to author
Forward
0 new messages