netdev - Re: Fw: [Bug 205339] New: epoll can fail to report a socket readable after enabling SO

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAPJVwB=PGn-V04kCHmoq0bk0fMUH9aS9-cE6j+cQ24-gtgfBWg@mail.gmail.com>
Date:   Mon, 28 Oct 2019 18:59:28 -0700
From:   Nathaniel Smith <njs@...ox.com>
To:     Eric Dumazet <eric.dumazet@...il.com>
Cc:     Stephen Hemminger <stephen@...workplumber.org>,
        netdev@...r.kernel.org
Subject: Re: Fw: [Bug 205339] New: epoll can fail to report a socket readable
 after enabling SO_OOBINLINE

On Mon, Oct 28, 2019 at 2:22 PM Eric Dumazet <eric.dumazet@...il.com> wrote:
> > -- Scenario 4: OOB data arrives -> register -> toggle SO_OOBINLINE=True --
> > select() says: sock is readable
> > epoll says: sock is NOT readable
> > reality: read succeeded
> >
>
> I really wonder how much energy we should put in maintaining this archaic thing.
>
> We do not have a single packetdrill test at Google using URG stuff.

Yeah, URG is pretty useless. I didn't find this because I was trying
to use URG; I found it because I was trying to avoid having to think
about URG :-).

The problem with URG is that it lets untrusted remote peers trivially
trigger weird socket semantics that most userspace developers haven't
tested or thought about at all. Once I started looking around I found
lots of prominent apps that react badly to receiving URG, plus there's
a history of nasty stuff like [1]. SO_OOBINLINE is interesting because
it makes the URG semantics more similar to the regular semantics that
apps are expecting, and empirically it would have mitigated lots of
these bugs. So I started wondering whether we should enable
SO_OOBINLINE unconditionally in the networking library I maintain, as
a general hardening measure, and while writing tests for that I
stumbled on this bug.

This specific bug is pretty unimportant... in practice you'd always
enable SO_OOBINLINE when a socket is created, not after you're already
polling it, so whatever. For the larger question about maintaining the
archaic URG code: having *some* kind of predictable semantics is
important! Though for me, even SO_OOBINLINE is fancier than I really
want; I'd be just as happy if the way to get boring, predictable
semantics was a simple SO_DISABLEOOBENTIRELY. I can also see an
argument for offering a system-level config option to disable URG
handling globally, and encouraging distros to turn it on...

-n

[1] https://sandstorm.io/news/2015-04-08-osx-security-bug

-- 
Nathaniel J. Smith -- https://vorpus.org