[HN Gopher] CTF Writeup: Abusing select() to factor RSA
       ___________________________________________________________________
        
       CTF Writeup: Abusing select() to factor RSA
        
       Author : moyix
       Score  : 70 points
       Date   : 2023-11-11 19:59 UTC (3 hours ago)
        
 (HTM) web link (threadreaderapp.com)
 (TXT) w3m dump (threadreaderapp.com)
        
       | jjnoakes wrote:
       | select() ought to just fail with EINVAL if nfds is too large.
       | There's probably an argument for the macros as well to fail by
       | default if the file descriptor given is too large.
        
         | moyix wrote:
         | As one safety measure, compiling with -DFORTIFY_SOURCE > 0 will
         | enable checks on the FD_SET etc macros:
         | 
         | https://github.com/bminor/glibc/commit/a0f33f996f7986dbf3763...
         | 
         | The kernel side interface probably won't change because
         | apparently legitimate apps have been allocating fd_sets on the
         | heap to monitor fds > 1024 and they don't want to break those:
         | 
         | https://sourceware.org/bugzilla/show_bug.cgi?id=10352#c7
         | 
         | The underlying problem was also discussed in an article by
         | Lennart Poettering (of systemd fame) and posted to HN back in
         | 2021:
         | 
         | https://news.ycombinator.com/item?id=27215690
         | 
         | https://0pointer.net/blog/file-descriptor-limits.html
        
           | warpspin wrote:
           | > The kernel side interface probably won't change because
           | apparently legitimate apps have been allocating fd_sets on
           | the heap to monitor fds > 1024 and they don't want to break
           | those
           | 
           | Rightly so. Before libev, AIO or whatever where a thing, I
           | used to run network servers 10 or 15 years or so ago with a
           | redefined __FD_SETSIZE set to 16384 without any problems on
           | Linux (plus appropriate proc and ulimit settings). The whole
           | stack properly supported it, even if not officially
           | supported.
           | 
           | The real problem nowadays is, people can easily receive a fd
           | >= 1024 as you do not control them, and then put them into fd
           | sets only supporting values up to 1023 and then you have a
           | security problem. Plus of course, the later APIs also simply
           | scale better beyond 16k connections.
        
             | syncsynchalt wrote:
             | I'm guessing you didn't/couldn't use poll(2) because of the
             | performance hit (both user and kernel side) of
             | parsing/checking the less compact data structure?
             | 
             | I both miss and don't miss the days before epoll(2) et al.
        
       | chc4 wrote:
       | I love well designed POSIX APIs, such as "this will silently
       | corrupt memory if you use an FD above FD_SETSIZE, which you have
       | no control over and have no sane way of remapping if it does
       | happen".
        
         | deathanatos wrote:
         | ...right?
         | 
         | The API design is patently insane, but why can't there be a
         | simple                 if(nfds > FD_SETSIZE) {         errno =
         | EINVAL;         return -1;       }
         | 
         | ... or something to prevent "the API is garbage" from
         | escalating all the way into "and now your memory is corrupt and
         | the hackers are in"...?
        
           | 95014_refugee wrote:
           | Because the code was written before unit tests were a thing,
           | and nobody is willing to take the risk / do the work to fix
           | it, especially when "it's been shipping for years and nobody
           | has ever complained".
        
         | jcalvinowens wrote:
         | > which you have no control over
         | 
         | It's not quite that bad: UNIX has always guaranteed open() will
         | return the lowest unused file descriptor. So in practice, it
         | just limits you to 1024 total open files in the process, which
         | in all fairness probably seemed like an absurdly large number
         | at the time it was designed.
        
       | kelsey9876543 wrote:
       | Excellent writeup. Thank you.
        
       | cjbprime wrote:
       | CTF writeups are so fun. Here's another I enjoyed, written by a
       | teammate: https://zackorndorff.com/2022/08/06/blazin-etudes-hack-
       | a-sat...
        
       ___________________________________________________________________
       (page generated 2023-11-11 23:00 UTC)