Sendmail, lynx, Netscape, sshd, Linux kernel (twice)

[lcamtuf () IDS PL (Michal Zalewski)]

// greetings to kotka :>
// ...and everyone who could stand this post

Hello boys and girls - probably everyone yearn after me :~( So I decided
to publish some more or less recent stuff, and increase traffic on this
beautiful list.

Sendmail x.x.x DoS
------------------

Take a look at this piece of code (src/daemon.c):

                        t = accept(DaemonSocket,
                            (struct sockaddr *)&RealHostAddr, &lotherend);
                        if (t >= 0 || errno != EINTR)
                                break;
                }
                savederrno = errno;
                (void) blocksignal(SIGALRM);
                if (t < 0)
                {
                        errno = savederrno;
                        syserr("getrequests: accept");

                        /* arrange to re-open the socket next time around */
                        (void) close(DaemonSocket);
                        DaemonSocket = -1;
                        refusingconnections = TRUE;
                        sleep(5);
                        continue;
                }

What we have here? Hmm, if accept() fails and syscall return code != EINTR,
Sendmail writes warning message and refuses connections for 5 seconds.
Hmm... Cute, isn't it?;> What about 'Connection reset by peer'?:) Our
algorithm is simple:

1. Send SYN from port X to victim, dst_port=25 (victim sends SYN/ACK)
2. Send RST from port X to victim, dst=port=25 respecting sequence numbers
   (victim got error on accept() - and enters 5 sec 'refusingconn' mode)
3. Wait approx. 2 seconds
4. Go to 1.

So, by sending just a few bytes every two seconds, we could completely
lock sendmail service. There's no reason to post any exploits. RFC +
any source (teardrop is good) + 'tcpdump -x' + 15 minutes = exploit.

Solution: remove this stupid sleep(...), and probably whole if (t < 0)
handler. Replace it with continue;

Bugs in lynx 2.8.x (including latest development versions):
-----------------------------------------------------------

Trivial overflows in protocol handlers:

<a href="rlogin://(approx. 1454 times 'A')">...</a>,
<a href="telnet://(approx. 1454 times 'A')">...</a> or
<a href="tn3270://(approx. 1454 times 'A')">...</a>

Choose your favourite protocol. Beautiful SEGV at 0x41414141. Also,
overflows in finger://, cso://, nntp:// and news:// handlers,
unfortunately not-so-easily exploitable. 1454 bytes is more than perfect
for common lynx 2.8.x under Linux. May vary under other platforms.

Not much to say. I reported similar overflow in mailto: protocol months
ago. I have no idea why it hasn't been fixed.

Samples: http://dione.ids.pl/~lcamtuf/pliki/browsers.html.gz

Solution: ehh...

Now, some DoSes on Netscape 4.0x browsers:
------------------------------------------

Meta refresh or href to URL "mocha:document.open('300k times A');" causes
netscape to waste whole memory / CPU, then crash. This URL could be gziped
to about 500 bytes, netscape will uncompress .html.gz web page in the fly.
Btw. by using 'mocha:' or 'javascript:' protocol in addresses, you could
do really interesting things, including "mocha:while(1)open();", but it's
nothing really uncommon - javascript extensions are harmful at all.

Want more? Insert meta refresh or href to "about:(300k times A)". Netscape
under Xwindows will hang up due to out-of-range draw request.

More and more tricks. With nethelp installed, URL
'nethelp:../../../../../anyfile%00' will cause netscape to seek through
any specified file looking for help (what about /dev/urandom?).
'view-source:' protocol is also really interesting.

Samples: http://dione.ids.pl/~lcamtuf/pliki/browsers.html.gz

Solution: (sorry, I haven't sources)

Maybe some sshd 1.x/2.0 stupidities:
------------------------------------

Unprivledged luser could create symlink in ~/.ssh (or ~/.sshd) to
virtually any file - root's ~/.ssh entries, /dev/urandom or anything else.
Sshd, during login attempt, but before any authorization, will happily
read these files, ignoring ownership (yep, it's running at UID 0). Could
be dangerous, could be not. But even if not, still allows some interesting
DoSes from privledged UID.

Linux kernel: execve & non-readable executables
-----------------------------------------------

Days ago - discussion about dumping executable-only processes using
linker tricks. Don't force open doors. This process, just like any
other, has 'dumpable' flag set to 1, and it could be ptraced (and
coure could be dumped). Of course, it SHOULD be threated just like
setuid process. Solution: http://dione.ids.pl/~lcamtuf/pliki/noreadx.c

More kernel 'things' - tty allocation
-------------------------------------

Hmm, I've posted it months ago, and I have no idea why it hasn't been
approved. Hmm, the problem: run 'mc' and enter: "ls -l `tty`". Not
much to say. Default Linux semantics won't allow non-suid programs to
allocate tty properly (it could be allocated, but in world-writable and
world-readable mode). Two solutions:

1. Give +s to Midnight Commander and other programs ;>
2. Remove +s from screen, xterm, rxvt, mc ;> and use this module instead:
   http://dione.ids.pl/~lcamtuf/pliki/ttyperm.c (*Solution*)

It changes Linux semantics on tty allocation to make it SYSV-alike. From
now, you could even use non-suid screen - export SCREENDIR=~/screens in
login scripts should be sufficient.

_______________________________________________________________________
Michal Zalewski [lcamtuf () ids pl] [ENSI / marchew] [dione.ids.pl SYSADM]
[http://linux.lepszy.od.kobiety.pl/~lcamtuf/] <=--=> bash$ :(){ :|:&};:
[voice phone: +48 (0) 22 813 25 86] ? [pager (MetroBip): 0 642 222 813]
Iterowac jest rzecza ludzka, wykonywac rekursywnie - boska [P. Deutsch]