Re: DEFAULT_MMAP_MIN_ADDR change breaks ssh on arm
On Wed, Mar 19, 2008 at 12:06 PM, maximilian attems [EMAIL PROTECTED] wrote: [ adding relevant cc peoples to your message, no more insight ] On Wed, Mar 19, 2008 at 06:46:37PM +0100, Martin Michlmayr wrote: The following change r10769 | maks | 2008-03-10 17:03:03 +0100 (Mon, 10 Mar 2008) | 8 lines security: set DEFAULT_MMAP_MIN_ADDR to 65536 Low address space to protect from user allocation, see a5ecbcb8c13ea8a822d243bf782d0dc9525b4f84, runtime tunable on /proc/sys/vm/mmap_min_addr. let's see if we get any fallout. double checked after Kconfig recommendation that fedora uses that recommendation too. breaks ssh on arm. While root can still log in via ssh, normal users cannot. ssh almost manages to log in but when it comes to starting a shell the connection simply closes. Changing DEFAULT_MMAP_MIN_ADDR back to 0 fixes this. maks, should I simply set DEFAULT_MMAP_MIN_ADDR to 0 on ARM or should I report this to the SE Linux folks or someone else? I've no idea how SE Linux works, so any help is welcome. On the GLAN Tank, values larger than 32768 cause ssh to fail, whereas 32768 and lower allow ssh to work. However, it appears that the exploit (CVE-2008-0600) is fixed in kernel versions 2.6.22.18 and above, 2.6.23.16 and above, 2.6.24.2 and above, and all 2.6.25 versions [1], so why can't we set DEFAULT_MMAP_MIN_ADDR to 0 for all architectures? Alternatively, would it help to enable SELinux for ARM? This idea is based on the help in security/Kconfig: config SECURITY_DEFAULT_MMAP_MIN_ADDR int Low address space to protect from user allocation depends on SECURITY default 0 help This is the portion of low virtual memory which should be protected from userspace allocation. Keeping a user from writing to low pages can help reduce the impact of kernel NULL pointer bugs. For most users with lots of address space a value of 65536 is reasonable and should cause no problems. Programs which use vm86 functionality would either need additional permissions from either the LSM or the capabilities module or have this protection disabled. This value can be changed after boot using the /proc/sys/vm/mmap_min_addr tunable. Gordon [1] http://kerneltrap.org/Linux/Patching_CVE-2008-0600_Local_Root_Exploit -- Gordon Farquharson GnuPG Key ID: 32D6D676 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DEFAULT_MMAP_MIN_ADDR change breaks ssh on arm
On Thu, Mar 20, 2008 at 07:12:22AM -0600, Gordon Farquharson wrote: On the GLAN Tank, values larger than 32768 cause ssh to fail, whereas 32768 and lower allow ssh to work. Which nicely ties up with the default address for binaries to be mapped (0x8000). Therefore, I suggest that the decision to change the default value of this without first consulting the architecture maintainers was a very bad move. If folk want to continue to have a non-zero default for this definition, it should be no higher than 32768. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
DEFAULT_MMAP_MIN_ADDR change breaks ssh on arm
The following change r10769 | maks | 2008-03-10 17:03:03 +0100 (Mon, 10 Mar 2008) | 8 lines security: set DEFAULT_MMAP_MIN_ADDR to 65536 Low address space to protect from user allocation, see a5ecbcb8c13ea8a822d243bf782d0dc9525b4f84, runtime tunable on /proc/sys/vm/mmap_min_addr. let's see if we get any fallout. double checked after Kconfig recommendation that fedora uses that recommendation too. breaks ssh on arm. While root can still log in via ssh, normal users cannot. ssh almost manages to log in but when it comes to starting a shell the connection simply closes. Changing DEFAULT_MMAP_MIN_ADDR back to 0 fixes this. maks, should I simply set DEFAULT_MMAP_MIN_ADDR to 0 on ARM or should I report this to the SE Linux folks or someone else? I've no idea how SE Linux works, so any help is welcome. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DEFAULT_MMAP_MIN_ADDR change breaks ssh on arm
[ adding relevant cc peoples to your message, no more insight ] On Wed, Mar 19, 2008 at 06:46:37PM +0100, Martin Michlmayr wrote: The following change r10769 | maks | 2008-03-10 17:03:03 +0100 (Mon, 10 Mar 2008) | 8 lines security: set DEFAULT_MMAP_MIN_ADDR to 65536 Low address space to protect from user allocation, see a5ecbcb8c13ea8a822d243bf782d0dc9525b4f84, runtime tunable on /proc/sys/vm/mmap_min_addr. let's see if we get any fallout. double checked after Kconfig recommendation that fedora uses that recommendation too. breaks ssh on arm. While root can still log in via ssh, normal users cannot. ssh almost manages to log in but when it comes to starting a shell the connection simply closes. Changing DEFAULT_MMAP_MIN_ADDR back to 0 fixes this. maks, should I simply set DEFAULT_MMAP_MIN_ADDR to 0 on ARM or should I report this to the SE Linux folks or someone else? I've no idea how SE Linux works, so any help is welcome. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DEFAULT_MMAP_MIN_ADDR change breaks ssh on arm
breaks ssh on arm. While root can still log in via ssh, normal users cannot. ssh almost manages to log in but when it comes to starting a shell the connection simply closes. Changing DEFAULT_MMAP_MIN_ADDR back to 0 fixes this. ... I should mention that it's not a ssh problem per se, but one with PAM. Logging in on the serial console also fails in the same way (see below). I believe Gordon Farquharson, who originally found this problem, has some more debugging information. Transcript: debian login: tbm Password: Last login: Wed Mar 19 17:57:46 CET 2008 from 192.168.1.22 on pts/0 Linux debian 2.6.25-rc6-iop32x #9 Wed Mar 19 17:38:35 UTC 2008 armv5tel The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. Debian GNU/Linux lenny/sid debian ttyS0 debian login: -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DEFAULT_MMAP_MIN_ADDR change breaks ssh on arm
Hi All On Wed, Mar 19, 2008 at 12:45 PM, Martin Michlmayr [EMAIL PROTECTED] wrote: I believe Gordon Farquharson, who originally found this problem, has some more debugging information. I'll send this information when I get home this evening. Essentially, it is the output from 'sshd -d -d -d' when I try to connect with a non-root user. In the meantime, here is a page that may (or may not) provide some more information. http://inz.fi/blog/2008/01/17/scratchbox-on-hardy/ I should note that 'su' and 'login' also fail for non-root users. Martin, did you say that you don't see this problem on the Thecus N2100 (iop32x)? I've seen it on the Linksys NSLU2 (ixp4xx) and the GLAN Tank (iop32x). Gordon -- Gordon Farquharson GnuPG Key ID: 32D6D676 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DEFAULT_MMAP_MIN_ADDR change breaks ssh on arm
* Gordon Farquharson [EMAIL PROTECTED] [2008-03-19 13:09]: Martin, did you say that you don't see this problem on the Thecus N2100 (iop32x)? No, I see it there as well. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DEFAULT_MMAP_MIN_ADDR change breaks ssh on arm
Hi All On Wed, Mar 19, 2008 at 1:09 PM, Gordon Farquharson [EMAIL PROTECTED] wrote: On Wed, Mar 19, 2008 at 12:45 PM, Martin Michlmayr [EMAIL PROTECTED] wrote: I believe Gordon Farquharson, who originally found this problem, has some more debugging information. I'll send this information when I get home this evening. Essentially, it is the output from 'sshd -d -d -d' when I try to connect with a non-root user. Here is the debug information from sshd with -d -d -d. Restarting OpenBSD Secure Shell server: sshddebug2: load_server_config: filename /etc/ssh/sshd_config debug2: load_server_config: done config len = 660 debug2: parse_server_config: config /etc/ssh/sshd_config len 660 debug3: /etc/ssh/sshd_config:5 setting Port 22 debug3: /etc/ssh/sshd_config:8 setting ListenAddress 0.0.0.0 debug3: /etc/ssh/sshd_config:9 setting Protocol 2 debug3: /etc/ssh/sshd_config:11 setting HostKey /etc/ssh/ssh_host_rsa_key debug3: /etc/ssh/sshd_config:12 setting HostKey /etc/ssh/ssh_host_dsa_key debug3: /etc/ssh/sshd_config:14 setting UsePrivilegeSeparation yes debug3: /etc/ssh/sshd_config:17 setting KeyRegenerationInterval 3600 debug3: /etc/ssh/sshd_config:18 setting ServerKeyBits 768 debug3: /etc/ssh/sshd_config:21 setting SyslogFacility AUTH debug3: /etc/ssh/sshd_config:22 setting LogLevel DEBUG debug3: /etc/ssh/sshd_config:25 setting LoginGraceTime 120 debug3: /etc/ssh/sshd_config:26 setting PermitRootLogin yes debug3: /etc/ssh/sshd_config:27 setting StrictModes yes debug3: /etc/ssh/sshd_config:29 setting RSAAuthentication yes debug3: /etc/ssh/sshd_config:30 setting PubkeyAuthentication yes debug3: /etc/ssh/sshd_config:34 setting IgnoreRhosts yes debug3: /etc/ssh/sshd_config:36 setting RhostsRSAAuthentication no debug3: /etc/ssh/sshd_config:38 setting HostbasedAuthentication no debug3: /etc/ssh/sshd_config:43 setting PermitEmptyPasswords no debug3: /etc/ssh/sshd_config:47 setting ChallengeResponseAuthentication no debug3: /etc/ssh/sshd_config:62 setting X11Forwarding yes debug3: /etc/ssh/sshd_config:63 setting X11DisplayOffset 10 debug3: /etc/ssh/sshd_config:64 setting PrintMotd no debug3: /etc/ssh/sshd_config:65 setting PrintLastLog yes debug3: /etc/ssh/sshd_config:66 setting TCPKeepAlive yes debug3: /etc/ssh/sshd_config:73 setting AcceptEnv LANG LC_* debug3: /etc/ssh/sshd_config:75 setting Subsystem sftp /usr/lib/openssh/sftp-server debug3: /etc/ssh/sshd_config:77 setting UsePAM yes debug1: sshd version OpenSSH_4.7p1 Debian-2 debug3: Not a RSA1 key file /etc/ssh/ssh_host_rsa_key. debug1: read PEM private key done: type RSA debug1: private host key: #0 type 1 RSA debug3: Not a RSA1 key file /etc/ssh/ssh_host_dsa_key. debug1: read PEM private key done: type DSA debug1: private host key: #1 type 2 DSA debug1: rexec_argv[0]='/usr/sbin/sshd' debug1: rexec_argv[1]='-d' debug1: rexec_argv[2]='-d' debug1: rexec_argv[3]='-d' debug2: fd 3 setting O_NONBLOCK debug1: Bind to port 22 on 0.0.0.0. Server listening on 0.0.0.0 port 22. debug3: fd 4 is not O_NONBLOCK debug1: Server will not fork when running in debugging mode. debug3: send_rexec_state: entering fd = 7 config len 660 debug3: ssh_msg_send: type 0 debug3: send_rexec_state: done debug1: rexec start in 4 out 4 newsock 4 pipe -1 sock 7 debug1: inetd sockets after dupping: 3, 3 Connection from 192.168.1.65 port 36502 debug1: Client protocol version 2.0; client software version OpenSSH_4.3p2 Debian-9 debug1: match: OpenSSH_4.3p2 Debian-9 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_4.7p1 Debian-2 debug2: fd 3 setting O_NONBLOCK debug3: privsep user:group 100:65534 debug1: permanently_set_uid: 100/65534 debug1: list_hostkey_types: ssh-rsa,ssh-dss debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,[EMAIL PROTECTED],aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,[EMAIL PROTECTED],aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[EMAIL PROTECTED],hmac-ripemd160,[EMAIL PROTECTED],hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[EMAIL PROTECTED],hmac-ripemd160,[EMAIL PROTECTED],hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,[EMAIL PROTECTED] debug2: kex_parse_kexinit: none,[EMAIL PROTECTED] debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2:
Re: DEFAULT_MMAP_MIN_ADDR change breaks ssh on arm
Hi Martin On Wed, Mar 19, 2008 at 11:46 AM, Martin Michlmayr [EMAIL PROTECTED] wrote: The following change r10769 | maks | 2008-03-10 17:03:03 +0100 (Mon, 10 Mar 2008) | 8 lines security: set DEFAULT_MMAP_MIN_ADDR to 65536 Low address space to protect from user allocation, see a5ecbcb8c13ea8a822d243bf782d0dc9525b4f84, runtime tunable on /proc/sys/vm/mmap_min_addr. let's see if we get any fallout. double checked after Kconfig recommendation that fedora uses that recommendation too. breaks ssh on arm. While root can still log in via ssh, normal users cannot. ssh almost manages to log in but when it comes to starting a shell the connection simply closes. Changing DEFAULT_MMAP_MIN_ADDR back to 0 fixes this. maks, should I simply set DEFAULT_MMAP_MIN_ADDR to 0 on ARM or should I report this to the SE Linux folks or someone else? I've no idea how SE Linux works, so any help is welcome. On the GLAN Tank, values larger than 32768 cause ssh to fail, whereas 32768 and lower allow ssh to work. However, it appears that the exploit CVE-2008-0600 is fixed in kernel versions 2.6.22.18 and above, 2.6.23.16 and above, 2.6.24.2 and above, and all 2.6.25 versions [1], so why can't we set DEFAULT_MMAP_MIN_ADDR to 0 for all architectures? Gordon [1] http://kerneltrap.org/Linux/Patching_CVE-2008-0600_Local_Root_Exploit -- Gordon Farquharson GnuPG Key ID: 32D6D676 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
