sshd is core dumping on my system if my ~/.ssh/authorized_keys file has invalid permissions (say, 666 instead of 400). The culprit is in auth2-pubkey.c, in the user_key_allowed2() function. Specifically, the line: secure_filename(f, file, pw, line, sizeof(line)); Problems with this: line is declared as "char *line;", not "char line[...];". Thus, sizeof() cannot be used to obtain the size of the buffer. line is uninitialized here (it's an OUT parameter to receive the error messgage). You might see an "Authentication failed: bad " entry in your /var/log/auth.log (though sshd can crash before it even gets that far). Note: this is a security risk. Reproducible: Always Steps to Reproduce: 1. Start sshd with "/usr/sbin/sshd -D -d -d -d" (debugging session). 2. Create ~/.ssh/authorized_keys file. 3. chmod 666 ~/.ssh/authorized_keys 4. From a remote machine, make sure you have a valid ~/.ssh/id_rsa identity file (ssh-keygen if you don't). 5. From the remote machine, log in to the machine with sshd. Actual Results: Connection closed on the remote machine. Segmentation fault on the local machine. Expected Results: Produced an error message in /var/log/auth.log.
My 'emerge info' if you are curious: Portage 2.0.51-r15 (default-linux/x86/2004.0, gcc-3.3.4, glibc-2.3.4.20041102-r0, 2.6.10-gentoo-r1 i686) ================================================================= System uname: 2.6.10-gentoo-r1 i686 AMD Athlon(tm) XP 1800+ Gentoo Base System version 1.6.9 Python: dev-lang/python-2.2.3-r5,dev-lang/python-2.3.4 [2.3.4 (#1, Jun 12 2004, 00:29:36)] ccache version 2.3 [enabled] dev-lang/python: 2.2.3-r5, 2.3.4 sys-devel/autoconf: 2.59-r6, 2.13 sys-devel/automake: 1.8.5-r2, 1.8.5-r1, 1.9.3, 1.9.4 sys-devel/binutils: 2.15.92.0.2-r2 sys-devel/libtool: 1.5.10-r3, 1.5.10-r4, 1.5.10-r2 virtual/os-headers: 2.4.22 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="no" CFLAGS="-O2 -march=i686 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/bind /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=i686 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks keeptemp keepwork noclean notitles sandbox sfperms" GENTOO_MIRRORS="http://gentoo.mirrors.pair.com/ http://gentoo.oregonstate.edu http://www.ibiblio.org/pub/Linux/distributions/gentoo" LANG="en_US" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage" USE="x86 3dnow X Xaw3d aalib acpi apm arts avi berkdb bitmap-fonts bonobo boundschecking canna cdr cjk crypt cups curl dga directfb doc dvd emboss encode esd f77 fam fbcon flac font-server foomaticdb fortran freewnn gcj gdbm ggi gif gnome gphoto2 gpm gps gstreamer gtk gtk2 gtkhtml guile imagemagick imap imlib ipv6 java jikes jpeg kde ldap libg++ libwww mad mbox mikmod mmx motif mozilla mpeg mpi mule mysql ncurses nls objc oggvorbis opengl oss pam pdflib perl plotutils png postgres python qt quicktime readline ruby samba scanner sdl slang speex spell sse ssl svga tcltk tcpd tetex tiff truetype truetype-fonts type1-fonts usb wmf xinerama xinetd xml xml2 xmms xv zlib" Unset: ASFLAGS, CBUILD, CTARGET, LC_ALL, LDFLAGS
I was not able to reproduce a crash with 3.9_p1-r1, the mentioned declaration of line is introduced by the largekey.patch btw. aliz, vapier... any comment/advise?
What do you see in /var/log/auth.log (assuming you have authorization messages going there) as a result? If you're triggering the bug, you'll see something like: Feb 18 20:36:49 sydney sshd[3407]: Authentication refused: bad It should read: Feb 18 20:36:49 sydney sshd[3407]: Authentication refused: bad ownership or modes for file (...) The former is writing into random memory, which may or may not cause a segfault. It is still a security risk.
Just quickly tested this (with propolice at compile-time); I'm unable to reproduce it. However, the use of sizeof() is still invalid, as you point out; the sizeof() argument passed to secure_filename() is used within that function with snprintf() to prevent writing too much to the pointer given (referred to as "err" in that scope). As Mr. Cuthbert points out, this won't work as it's used. I suppose one could control the contents of the buf variable that is written to err by controlling the directory name that is printed in the debug message (of course, this relies on debugging being turned on, it looks like), so conceivably have some control over what is written to the heap (or wherever char * line happens to point--since it's uninitialized, odds are it'll just be a segfault). So I suppose this isn't hypothetically completely inexploitable--in other words, I'm not willing to say that it's nothing more than a bug. Anyway, short story is, can we get this fixed? I'm CC'ing hardened, as well, because they're listed as maintainers.
Probably not exploitable -- an attacker won't be able to specify either the string written or where it's written. At most a DoS. I still get nervous, though, anytime a daemon is writing to a bad pointer; I still get surprised at the cleverness of some attacks.
david's analysis is spot on ... - secure_filename(f, file, pw, line, sizeof(line)) != 0) { + secure_filename(f, file, pw, line, size) != 0) { that should fix it up fine ... i've committed the fix, but i'll hold off on making openssh 3.9_p1-r2 until we get Bug 82372 fixed (shouldnt be long) ... and as you note, it doesnt *seem* like it's exploitable
I might have missed it in the patch for bug 82372, but I didn't see an initialization for line and size. They're initialized a few lines further down. You can move the init up, but be sure to xfree(line) after the logit() call in the if block.
hmm, that too is spot on :) i'll fix that up and get back to you
Definitely a bug, but not a security issue (DoSing yourself), reassigning
ive removed the largekeys patch since it's badly broken as you can see from this bug downgrading severity; we need a largekey patch which doesnt suck ;)
Re-assign.
the largekey stuff has been disabled for a while
Hm, had forgotten that this bug even existed. Anyway, if it's disabled, alles gut.
