Re: security.debian.org is down
I can ping it, and I just did an apt-get update which connected fine. Maybe it just came back up. Yes, it came back! Everything fine now ! ;-) Cheers Jonas -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
New version of SSH refusing login
Good evening, all. I just went through the upgrade of SSH, and now I cannot log into my potatoe box. Luckly, I did keep a session logged in, for debugging don't you know. So I can say that the debug error is as follows: Jun 25 21:35:33 ian sshd[12644]: debug1: Starting up PAM with username howland Jun 25 21:35:33 ian sshd[12644]: Could not reverse map address 165.76.163.213. Jun 25 21:35:33 ian sshd[12644]: debug1: PAM setting rhost to 165.76.163.213 Jun 25 21:35:33 ian sshd[12644]: Failed none for howland from 165.76.163.213 port 33226 ssh2 That's a great debug message, Failed none. None what? Any help would be greatly appreciated. Curt- -- September 11th, 2001 The proudest day for gun control and central planning advocates in American history -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
SSH upgrade update / resolution
Ok, it's resolved. I have never generated keys for ssh2 so, rather than fall back to ssh1, it just fails. If I tell the client to force ssh1 ssh -1, it works with the ssh1 RSA keys just fine. If I turn on password authentication, it fails back to that just fine. I guess if the server and client are both capable of ssh2 it just never bothers to try ssh1. Also, I really Really REALLY do not want to leave password authentication turned on. So, question to those who have tried this, are there any complications with generating ssh2 keys? Any chance of overwriting (accidentally) the ssh1 keys? Curt- -- September 11th, 2001 The proudest day for gun control and central planning advocates in American history -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
non-us.debian.org is down
I am installing Debian but having problem to connect to non-us.debian.org, Pls help. Thanks. Fong Chu - Original Message - From: Jonas Weismüller [EMAIL PROTECTED] To: debian-security@lists.debian.org Sent: Wednesday, June 26, 2002 12:02 PM Subject: Re: security.debian.org is down I can ping it, and I just did an apt-get update which connected fine. Maybe it just came back up. Yes, it came back! Everything fine now ! ;-) Cheers Jonas -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-us.debian.org is down
Ng Fong Chu wrote: I am installing Debian but having problem to connect to non-us.debian.org, Pls help. Thanks. Fong Chu Have you tried the mirrors? deb http://ftp.jp.debian.org/debian-non-US testing/non-US main contrib non-free -- September 11th, 2001 The proudest day for gun control and central planning advocates in American history -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-us.debian.org is down
Both are on SurfNet in The netherlands, I suppose they went down for a short while or the connection between your ISP and Surf went down. Greetings, Ivo van Dongen -Original Message- From: Ng Fong Chu [EMAIL PROTECTED] Date: Wed, 26 Jun 2002 13:51:06 +0800 Subject: non-us.debian.org is down I am installing Debian but having problem to connect to non-us.debian.org, Pls help. Thanks. Fong Chu - Original Message - From: Jonas Weismüller [EMAIL PROTECTED] To: debian-security@lists.debian.org Sent: Wednesday, June 26, 2002 12:02 PM Subject: Re: security.debian.org is down I can ping it, and I just did an apt-get update which connected fine. Maybe it just came back up. Yes, it came back! Everything fine now ! ;-) Cheers Jonas -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: New version of SSH refusing login
Back it out... If you read the release notes you would have seen that the ssh upgrade has problems with PAM. Use something like IPCHAINS or IPTABLES to restrict which IP addresses are allowed to access your box via SSH until such time that SSH using privilege separation handles PAM properly. Oh, please check existing bug reports and file a new one if one dosen't already exist for your problem. Curt Howland wrote: Good evening, all. I just went through the upgrade of SSH, and now I cannot log into my potatoe box. Luckly, I did keep a session logged in, for debugging don't you know. So I can say that the debug error is as follows: Jun 25 21:35:33 ian sshd[12644]: debug1: Starting up PAM with username howland Jun 25 21:35:33 ian sshd[12644]: Could not reverse map address 165.76.163.213. Jun 25 21:35:33 ian sshd[12644]: debug1: PAM setting rhost to 165.76.163.213 Jun 25 21:35:33 ian sshd[12644]: Failed none for howland from 165.76.163.213 port 33226 ssh2 That's a great debug message, Failed none. None what? Any help would be greatly appreciated. -- | Bryan Andersen | [EMAIL PROTECTED] | http://www.nerdvest.com | | Buzzwords are like annoying little flies that deserve to be swatted. | | Linux, the OS Microsoft doesn't want you to know about.. | | -Bryan Andersen| -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SSH upgrade update / resolution
On Wed, Jun 26, 2002 at 02:35:09PM +0900, Curt Howland wrote: Ok, it's resolved. I have never generated keys for ssh2 so, rather than fall back to ssh1, it just fails. If I tell the client to force ssh1 ssh -1, it works with the ssh1 RSA keys just fine. If I turn on password authentication, it fails back to that just fine. I guess if the server and client are both capable of ssh2 it just never bothers to try ssh1. Also, I really Really REALLY do not want to leave password authentication turned on. So, question to those who have tried this, are there any complications with generating ssh2 keys? Any chance of overwriting (accidentally) the ssh1 keys? No it's quiet forward... As root, just do ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key brgds, /frax pgpo8eAnmZStu.pgp Description: PGP signature
Re: security.debian.org is down
It seems to be down again... I'm getting connection timed out messages, though, I was able to connect a half hour ago. On Tue, 2002-06-25 at 23:02, Jonas Weismüller wrote: Yes, it came back! Everything fine now ! ;-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: security.debian.org is down
On 26 Jun 2002, David Bell wrote: It seems to be down again... I'm getting connection timed out messages, though, I was able to connect a half hour ago. SurfNet (where s.d.o is hosted) is having some router gone wild. It tends to be down one minute and up a few later. They're working on the issue. They couldn't tell when it will be fixed. regards, Thomas -- - I intend to live forever - so far, so good -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problems with SSH Upgrade
Title: Re: Problems with SSH Upgrade Hi, Disabling protocol version 2. Could not load host key Restarting OpenBSD Secure Shell server: sshd Disabling protocol version 2. Could not load host key [SNIP] # This is ssh server systemwide configuration file. [SNIP] HostKey /etc/ssh/ssh_host_key I had the same problem. The sshd_config file is correct for ssh 1 but wrong for ssh 2. You should have something like this: HostKey /etc/ssh/ssh_host_key HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_dsa_key You should probably dpkg-reconfigure ssh and produce a new config file. Regards, -- Benoît Sibaud RD Engineer - France Telecom
PermitRootLogin enabled by default
Hi all Messing up with sshd_config for all the privsep stuff, I've noticed that PermitRootLogin was set to yes in my three woody boxes. I usually consider this a problem (although it has been my fault - i should have checked and noticed this much time ago). What do you think of this? IMHO, we'd better set it to no. I always thought it was much better. Is there any landscape in which you may want to allow direct root login to your host? Regards, Luis -- Luis Gómez Miralles InfoEmergencias - Technical Department Phone (+34) 654 24 01 34 Fax (+34) 963 49 31 80 [EMAIL PROTECTED] PGP Public Key available at http://www.infoemergencias.com/lgomez.asc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: PermitRootLogin enabled by default
Is there any landscape in which you may want to allow direct root login to your host? I allow it to my firewall, since there isnt any other account on there. but then again, that system only listens to my internal interfaces.. So, not typical maybe? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PermitRootLogin enabled by default
On Wed, Jun 26, 2002 at 02:11:00PM +0200, InfoEmergencias - Luis G?mez wrote: IMHO, we'd better set it to no. I always thought it was much better. Is there any landscape in which you may want to allow direct root login to your host? rsync where you want to keep userid/groupid info. -- GOVERNMENT ANNOUNCEMENT - The government announced today that it is changing its mascot to a condom because it more clearly reflects the government's political stance. A condom stands up to inflation, halts production, destroys the next generation, protects a bunch of pricks and finally, gives you a sense of security while you're being screwed! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PermitRootLogin enabled by default
I tend to set it to without-password to allow a remote root entry only via RSA/DSA keys, also making sure to restrict it further with as many applicable options for AuthorizedKeysFile ( man sshd ) This is done as a restricated remote root backdoor as well as automated network backups via dump restore. Leaving it set to yes is just an invitation for people to brute force the root password. -- Steve On 26 Jun 2002, InfoEmergencias - Luis Gómez wrote: Hi all Messing up with sshd_config for all the privsep stuff, I've noticed that PermitRootLogin was set to yes in my three woody boxes. I usually consider this a problem (although it has been my fault - i should have checked and noticed this much time ago). What do you think of this? IMHO, we'd better set it to no. I always thought it was much better. Is there any landscape in which you may want to allow direct root login to your host? Regards, Luis -- Luis Gómez Miralles InfoEmergencias - Technical Department Phone (+34) 654 24 01 34 Fax (+34) 963 49 31 80 [EMAIL PROTECTED] PGP Public Key available at http://www.infoemergencias.com/lgomez.asc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] [-] Steve Mickeler [ [EMAIL PROTECTED] ] [|] Todays root password is brought to you by /dev/random [+] 1024D/ACB58D4F = 0227 164B D680 9E13 9168 AE28 843F 57D7 ACB5 8D4F -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PermitRootLogin enabled by default
On Wed, Jun 26, 2002 at 02:11:00PM +0200 or thereabouts, InfoEmergencias - Luis Gómez wrote: Messing up with sshd_config for all the privsep stuff, I've noticed that PermitRootLogin was set to yes in my three woody boxes. I usually consider this a problem (although it has been my fault - i should have checked and noticed this much time ago). What do you think of this? disallowing direct root logins via ssh provides for auditing. you will always know which user became root. this is why i keep PermitRootLogin turned off. regards, uLI -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PermitRootLogin enabled by default
On Wed, Jun 26, 2002 at 04:05:58PM +0200, Christoph Ulrich Scholler wrote: On Wed, Jun 26, 2002 at 02:11:00PM +0200 or thereabouts, InfoEmergencias - Luis Gómez wrote: Messing up with sshd_config for all the privsep stuff, I've noticed that PermitRootLogin was set to yes in my three woody boxes. I usually consider this a problem (although it has been my fault - i should have checked and noticed this much time ago). What do you think of this? disallowing direct root logins via ssh provides for auditing. you will always know which user became root. this is why i keep PermitRootLogin turned off. Right, unless you actually want to use keys, which is the whole point. Just up the logging level and it will say which keys are logging in, and then you'll never have to transmit your root password to the server. Using su root later is worse than just logging in as root with a key. Simon- [Simon Kirby][Network Operations] [ [EMAIL PROTECTED] ][ NetNation Communications ] [ Opinions expressed are not necessarily those of my employer. ] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PermitRootLogin enabled by default
Simon Kirby [EMAIL PROTECTED] writes: Using su root later is worse than just logging in as root with a key. I cannot understand why using su root later would be worse. Can you enlighten me? -- Christian Egli wyona: research development http://www.wyona.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Fwd: ISS Advisory: OpenSSH Remote Challenge Vulnerability]
Hi Mark, From the OpenSSH web page: At least one major security vulnerability exists in many deployed OpenSSH versions (2.9.9 to 3.3). Please see the ISS advisory, or our own OpenSSH advisory on this topic where simple patches are provided for the pre-authentication problem. Systems running with UsePrivilegeSeparation yes or ChallengeResponseAuthentication no are not affected. The 3.4 release contain many other fixes done over a week long audit started when this issue came to light. We believe that some of those fixes are likely to be important security fixes. Therefore, we urge an upgrade to 3.4. It sounds like there are other security holes fixed as well. -Anne This one time, Mark Janssen wrote: From what I understand, the advisory below is for the security issue we've been buggering over for the last 2-3 days. As I understand it, there is no need to upgrade to openssh 3.3 and use priv-sep code, when we turn of the various challenge-response systems discussed below (BSD-AUTH and SKEY). AFAIK many people don't need these (What does BSD-Auth do on debian) so we should be safe with the old 3.0.2/3.1 SSH packages and these options removed from the default install ??? Can anyone shed any light on this... -Forwarded Message- From: X-Force [EMAIL PROTECTED] To: bugtraq@securityfocus.com Subject: ISS Advisory: OpenSSH Remote Challenge Vulnerability Date: 26 Jun 2002 09:56:07 -0400 -BEGIN PGP SIGNED MESSAGE- Internet Security Systems Security Advisory June 26, 2002 OpenSSH Remote Challenge Vulnerability Synopsis: ISS X-Force has discovered a serious vulnerability in the default installation of OpenSSH on the OpenBSD operating system. OpenSSH is a free version of the SSH (Secure Shell) communications suite and is used as a secure replacement for protocols such as Telnet, Rlogin, Rsh, and Ftp. OpenSSH employs end-to-end encryption (including all passwords) and is resistant to network monitoring, eavesdropping, and connection hijacking attacks. X-Force is aware of active exploit development for this vulnerability. Impact: OpenBSD, FreeBSD-Current, and other OpenSSH implementations may be vulnerable to a remote, superuser compromise. Affected Versions: OpenBSD 3.0 OpenBSD 3.1 FreeBSD-Current OpenSSH 3.0-3.2.3 OpenSSH version 3.3 implements privilege separation which mitigates the risk of a superuser compromise. Prior to the release of this advisory, ISS and OpenBSD encouraged all OpenSSH users to upgrade to version 3.3. Versions of FreeBSD-Current built between March 18, 2002 and June 23, 2002 are vulnerable to remote superuser compromise. Privilege separation was implemented in FreeBSD-Current on June 23, 2002. Note: OpenSSH is included in many operating system distributions, networking equipment, and security appliances. Refer to the following address for information about vendors that implement OpenSSH: http://www.openssh.com/users.html Description: A vulnerability exists within the challenge-response authentication mechanism in the OpenSSH daemon (sshd). This mechanism, part of the SSH2 protocol, verifies a user's identity by generating a challenge and forcing the user to supply a number of responses. It is possible for a remote attacker to send a specially-crafted reply that triggers an overflow. This can result in a remote denial of service attack on the OpenSSH daemon or a complete remote compromise. The OpenSSH daemon runs with superuser privilege, so remote attackers can gain superuser access by exploiting this vulnerability. OpenSSH supports the SKEY and BSD_AUTH authentication options. These are compile-time options. At least one of these options must be enabled before the OpenSSH binaries are compiled for the vulnerable condition to be present. OpenBSD 3.0 and later is distributed with BSD_AUTH enabled. The SKEY and BSD_AUTH options are not enabled by default in many distributions. However, if these options are explicitly enabled, that build of OpenSSH may be vulnerable. Recommendations: Internet Scanner X-Press Update 6.13 includes a check, OpenSshRunning, to detect potentially vulnerable installations of OpenSSH. XPU 6.13 is available from the ISS Download Center at: http://www.iss.net/download. For questions about downloading and installing this XPU, email [EMAIL PROTECTED] ISS X-Force recommends that system administrators disable unused OpenSSH authentication mechanisms. Administrators can remove this vulnerability by disabling the Challenge-Response authentication parameter within the OpenSSH daemon configuration file. This filename and path is typically: /etc/ssh/sshd_config. To disable this parameter, locate the corresponding line and change it to the line below: ChallengeResponseAuthentication no The sshd process must be restarted for this change to take effect. This workaround will permanently remove the vulnerability. X-Force recommends that
Re: PermitRootLogin enabled by default
On Wed, Jun 26, 2002 at 04:05:58PM +0200, Christoph Ulrich Scholler wrote: On Wed, Jun 26, 2002 at 02:11:00PM +0200 or thereabouts, InfoEmergencias - Luis Gómez wrote: Messing up with sshd_config for all the privsep stuff, I've noticed that PermitRootLogin was set to yes in my three woody boxes. I usually consider this a problem (although it has been my fault - i should have checked and noticed this much time ago). What do you think of this? disallowing direct root logins via ssh provides for auditing. you will always know which user became root. this is why i keep PermitRootLogin turned off. Right, unless you actually want to use keys, which is the whole point. Just up the logging level and it will say which keys are logging in, and then you'll never have to transmit your root password to the server. Using su root later is worse than just logging in as root with a key. I don't know if I agree with that but if even if I grant you that for the sake of the argument, the sudo package is your friend. -- +-+-+ | [EMAIL PROTECTED] | Thou art the ruins of the noblest man | | Derek J. Balling | That ever lived in the tide of times. | | | Woe to the hand that shed this costly | | | blood - Julius Caesar Act 3, Scene 1 | +-+-+ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PermitRootLogin enabled by default
On Wed, Jun 26, 2002 at 05:08:32PM +0200, Christian Egli wrote: Simon Kirby [EMAIL PROTECTED] writes: Using su root later is worse than just logging in as root with a key. I cannot understand why using su root later would be worse. Can you enlighten me? Sure. In all cases, you always depend on the security of the client, whether it be protecting a key on the filesystem or protecting the keystrokes from being logged. If the client is compromised, anything can happen, regardless of if the client has to enter one password, two passwords, a key with one passphrase, or a key with ssh-agent. So, let us look at the server. If the server is compromised, often a password sniffer and/or trojaned SSH or su daemon will be installed. With passwords, as soon as the next administrator logs in and enters the password, via su or via ssh, the password will be decrypted to cleartext by the server for verification and thus logged. If this password happens to be used on any other server, the attacker will have access to those servers (you could have a different password for every server, but often this does not happen in practice). With keys, nothing special happens. The server can either allow or refuse the connection, and logging will accomplish nothing other than being able to determine the public key (which would already have to be on the server anyway). The attacker cannot obtain any password or private key information. This combined with the fact that logging in as root (preferrably with a key) makes things like scp and other non-interactive programs possible over SSH. I don't see any reason _not_ to log in directly as root. Logging is the only potential issue, but that can be fixed by altering the log level in sshd_config. (Remember we're talking about root access here. Anybody with root access can alter logs and/or transmit decoy logging entries to remote logging servers, etc., so logs for root logins aren't really that useful except for the Alright, who broke it? case.) Simon- [Simon Kirby][Network Operations] [ [EMAIL PROTECTED] ][ NetNation Communications ] [ Opinions expressed are not necessarily those of my employer. ] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PermitRootLogin enabled by default
On Wed, Jun 26, 2002 at 02:11:00PM +0200, InfoEmergencias - Luis Gómez wrote: IMHO, we'd better set it to no. I always thought it was much better. Is there any landscape in which you may want to allow direct root login to your host? Yes, there is. For example I have some servers that retrieve their user information from a database. If the database is not reachable, an ordinary user can't login, but root can, since it's the only local account with login privileges. But then this is a special case that doesn't require root logins enabled by default. On the other hand I don't see why allowing direct root logins is a problem. - Sebastian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PermitRootLogin enabled by default
El mié, 26-06-2002 a las 16:39, Sebastian Rittau escribió: Yes, there is. For example I have some servers that retrieve their user information from a database. If the database is not reachable, an ordinary user can't login, but root can, since it's the only local account with login privileges. Thanks to all of you for your replies. As I expected, there exist situations in which this is necessary, it's only I couldn't imagine those situations... So, again, thanks to all! -- Luis Gómez Miralles InfoEmergencias - Technical Department Phone (+34) 654 24 01 34 Fax (+34) 963 49 31 80 [EMAIL PROTECTED] PGP Public Key available at http://www.infoemergencias.com/lgomez.asc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PermitRootLogin enabled by default
Sebastian Rittau [EMAIL PROTECTED] writes: On Wed, Jun 26, 2002 at 02:11:00PM +0200, InfoEmergencias - Luis Gómez wrote: IMHO, we'd better set it to no. I always thought it was much better. Is there any landscape in which you may want to allow direct root login to your host? Yes, there is. For example I have some servers that retrieve their user information from a database. If the database is not reachable, an ordinary user can't login, but root can, since it's the only local account with login privileges. Yes, this is an idea, along with simple backups (over scp/rsync, without sudo server-side). Doesn't sashroot also constitute uid-0 login and fall subject to the above? But then this is a special case that doesn't require root logins enabled by default. On the other hand I don't see why allowing direct root logins is a problem. Having `PermitRootLogin yes' gives someone a known username to brute-force. Fortunately, sshd_config(5) to the rescue, here: | PermitRootLogin | Specifies whether root can login using ssh(1). The argument | must be ``yes'', ``without-password'', | ``forced-commands-only'' or ``no''. The default is ``yes''. For potentially-interactive purposes (rescuing a remote server), I'd go with without-password; if you know that root coming in via this access means is only going to want to run one command (eg for backup purposes when you have console access a matter of metres away) then you can afford the extra security of a forced-commands-only approach[0]. [0] Note FWIW that this is not you asked for the wrong command, so I'll do nothing; it's no matter what you asked, I'm going to do Foo as specified in the cmd= restriction... ~Tim -- http://spodzone.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Fwd: ISS Advisory: OpenSSH Remote Challenge Vulnerability]
I am a bit worried about the ssh advisories, not the actual package itself (well, that too) but the way it was handled -- the openssh team issued new versions of a package and a security advisory asking everyone to update to the new package, Debian and others jumped on it and sent the new version out. The possibility of distributing a wide scale worm or virus using this approach is obvious. This seems to relate to the discussion about security advisories violating the social contract as well. If the social contract was followed, there wouldn't be a security advisories based on information that the community cannot verify (in this case, I understand that not even the security officers could verify if the ssh package was vulnerable or not?). Only when someone points at the code that is bad, in public, and it is agreed that it is bad, only then should a security update be made. One (somewhat costly) way to solve this would be to have two kinds of security updates. One is made early and with information not available to the community, the other is made only when the community can verify security bugs. Users can decide which one they want to trust. Anyone share my concerns? /troll ;-) Anne Carasik [EMAIL PROTECTED] writes: Hi Mark, From the OpenSSH web page: At least one major security vulnerability exists in many deployed OpenSSH versions (2.9.9 to 3.3). Please see the ISS advisory, or our own OpenSSH advisory on this topic where simple patches are provided for the pre-authentication problem. Systems running with UsePrivilegeSeparation yes or ChallengeResponseAuthentication no are not affected. The 3.4 release contain many other fixes done over a week long audit started when this issue came to light. We believe that some of those fixes are likely to be important security fixes. Therefore, we urge an upgrade to 3.4. It sounds like there are other security holes fixed as well. -Anne This one time, Mark Janssen wrote: From what I understand, the advisory below is for the security issue we've been buggering over for the last 2-3 days. As I understand it, there is no need to upgrade to openssh 3.3 and use priv-sep code, when we turn of the various challenge-response systems discussed below (BSD-AUTH and SKEY). AFAIK many people don't need these (What does BSD-Auth do on debian) so we should be safe with the old 3.0.2/3.1 SSH packages and these options removed from the default install ??? Can anyone shed any light on this... -Forwarded Message- From: X-Force [EMAIL PROTECTED] To: bugtraq@securityfocus.com Subject: ISS Advisory: OpenSSH Remote Challenge Vulnerability Date: 26 Jun 2002 09:56:07 -0400 -BEGIN PGP SIGNED MESSAGE- Internet Security Systems Security Advisory June 26, 2002 OpenSSH Remote Challenge Vulnerability Synopsis: ISS X-Force has discovered a serious vulnerability in the default installation of OpenSSH on the OpenBSD operating system. OpenSSH is a free version of the SSH (Secure Shell) communications suite and is used as a secure replacement for protocols such as Telnet, Rlogin, Rsh, and Ftp. OpenSSH employs end-to-end encryption (including all passwords) and is resistant to network monitoring, eavesdropping, and connection hijacking attacks. X-Force is aware of active exploit development for this vulnerability. Impact: OpenBSD, FreeBSD-Current, and other OpenSSH implementations may be vulnerable to a remote, superuser compromise. Affected Versions: OpenBSD 3.0 OpenBSD 3.1 FreeBSD-Current OpenSSH 3.0-3.2.3 OpenSSH version 3.3 implements privilege separation which mitigates the risk of a superuser compromise. Prior to the release of this advisory, ISS and OpenBSD encouraged all OpenSSH users to upgrade to version 3.3. Versions of FreeBSD-Current built between March 18, 2002 and June 23, 2002 are vulnerable to remote superuser compromise. Privilege separation was implemented in FreeBSD-Current on June 23, 2002. Note: OpenSSH is included in many operating system distributions, networking equipment, and security appliances. Refer to the following address for information about vendors that implement OpenSSH: http://www.openssh.com/users.html Description: A vulnerability exists within the challenge-response authentication mechanism in the OpenSSH daemon (sshd). This mechanism, part of the SSH2 protocol, verifies a user's identity by generating a challenge and forcing the user to supply a number of responses. It is possible for a remote attacker to send a specially-crafted reply that triggers an overflow. This can result in a remote denial of service attack on the OpenSSH daemon or a complete remote compromise. The OpenSSH daemon runs with superuser privilege, so remote attackers can gain superuser access by exploiting this vulnerability. OpenSSH supports the SKEY and BSD_AUTH authentication options. These are compile-time options. At least one of these options
Re: [Fwd: ISS Advisory: OpenSSH Remote Challenge Vulnerability]
Hi Simon, This one time, [EMAIL PROTECTED] wrote: I am a bit worried about the ssh advisories, not the actual package itself (well, that too) but the way it was handled -- the openssh team issued new versions of a package and a security advisory asking everyone to update to the new package, Debian and others jumped on it and sent the new version out. The possibility of distributing a wide scale worm or virus using this approach is obvious. Always, always, check the digital signature. I don't think that Theo and co. would want to distribute a worm in this way. This would defeat their purpose for existence in the UNIX security world. I agree though.. it's really poorly handled. I really hope that's what the deb packagers do before creating the package. Speaking of which.. soapbox When is Debian going to implement SHA-1 checksums or gpg sigs into the apt-get, dpkg, and the debs before installing? This just trusting the deb source is really scary.. /soapbox violating the social contract as well. If the social contract was followed, there wouldn't be a security advisories based on information that the community cannot verify (in this case, I understand that not even the security officers could verify if the ssh package was vulnerable or not?). Only when someone points at the code that is bad, in public, and it is agreed that it is bad, only then should a security update be made. Wow, this and Apache all in a matter of weeks ;-). *sigh* I agree, especially since any monkey can go and audit the source themselves. One (somewhat costly) way to solve this would be to have two kinds of security updates. One is made early and with information not available to the community, the other is made only when the community can verify security bugs. Users can decide which one they want to trust. I would say use one or the other, but not both. This is something the security community should decide, not the users. You'll confuse the poor folks ;) Anyone share my concerns? /troll ;-) *raises hand* Both the Apache and OpenSSH announcements were done poorly, without any reasonable thought given to the user community. They should be taken out and shot ;-) (IMHO). -Anne -- .-.__.``. Anne Carasik, System Administrator .-.--. _...' (/) (/) ``' gator at cacr dot caltech dot edu (O/ O) \-' ` -==.', Center for Advanced Computing Research ~`~~ pgphq6WqICg8G.pgp Description: PGP signature
OpenSSH 3.4 released... should FIX problems
Head over to OpenSSH.com They have just released version 3.4, which should fix some overflow problems and adds lot's of new checks against dubious input. Advisories and updates on the various pages there. Mark Janssen Syconos IT Consultancy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DSA-134-1
Florian Weimer [EMAIL PROTECTED] writes: Wichert Akkerman [EMAIL PROTECTED] writes: Definitely. I really wish we could do more but the complete lack of more information we have make things difficult. Backporting OpenSSH 3.3p1 to to potato is also slightly complicated by missing build dependencies, but we hope to have packages ready sometime tomorrow. Is this worth the effort if there's still a remote nobody exploit? At least that's the way understand the DSA. Well, it appears if OpenSSH 1.2.3 was *not* vulnerable, so the whole exercise was rather pointless. Thanks, Theo. -- Florian Weimer[EMAIL PROTECTED] University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/ RUS-CERT fax +49-711-685-5898 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PermitRootLogin enabled by default
I think there may be a compromise solution here... In short: it is good to make people log in as a normal user before trying to log in as root, because that way an attacker needs to compromise a normal user before starting on root. The standard way of doing this is to use su, but that only accepts passwords, not (more secure) keypairs. On our system, we run two ssh processes - one on the external interface which does not accept root logins, and one on the internal interface which does (keypairs only). A remote user wanting to log in as root must first log in as a normal user, forwarding a connection to the local SSH port, then log in using the key stored on their own machine. As far as I can tell, this is the best of both worlds (although it does take some setting up!) - Andrew Sayers pgp67FjB1k1aX.pgp Description: PGP signature
Re: [Fwd: ISS Advisory: OpenSSH Remote Challenge Vulnerability]
I don't see a better way of handling the OpenSSH announcement. More details or a patch would have allowed people to start writing exploits, at least they warned users of an upcoming bug and provided a work around. The OpenSSH team had to communicate with many vendors and eventually the details would have leaked. While debian may have released patched ssh packages right away, how many thousands of users of other vendors out there wouldn't have had a patch? The apache announcement was just a mess though... -Greg *raises hand* Both the Apache and OpenSSH announcements were done poorly, without any reasonable thought given to the user community. They should be taken out and shot ;-) (IMHO). -Anne -- --SupplyEdge--- Greg Hunt 800-733-3380 x 107 [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DSA-134-1
On Wed, 2002-06-26 at 13:23, Florian Weimer wrote: Well, it appears if OpenSSH 1.2.3 was *not* vulnerable, so the whole exercise was rather pointless. Thanks, Theo. Worst advisory ever. -m -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [d-security] Re: DSA-134-1
On Wed, Jun 26, 2002 at 07:23:49PM +0200, Florian Weimer wrote: Well, it appears if OpenSSH 1.2.3 was *not* vulnerable, so the whole exercise was rather pointless. But drill inspector Theo (update and don't ask questions, soldier!), showed at least how good our new security upload architecture and how fast the security team is *g* Thanks, Theo. Don't be too hard to him, if he'd pointed out that only default BSD is vulnerable it would not have been too hard to find the exploit before everybody had updated. bye, -christian- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Fwd: ISS Advisory: OpenSSH Remote Challenge Vulnerability]
On Wednesday, 2002-06-26 at 18:14:35 +0200, Mark Janssen wrote: From what I understand, the advisory below is for the security issue we've been buggering over for the last 2-3 days. As I understand it, there is no need to upgrade to openssh 3.3 and use priv-sep code, when we turn of the various challenge-response systems discussed below (BSD-AUTH and SKEY). AFAIK many people don't need these (What does BSD-Auth do on debian) so we should be safe with the old 3.0.2/3.1 SSH packages and these options removed from the default install ??? Can anyone shed any light on this... -Forwarded Message- ... OpenSSH supports the SKEY and BSD_AUTH authentication options. These are compile-time options. At least one of these options must be enabled before the OpenSSH binaries are compiled for the vulnerable condition to be present. OpenBSD 3.0 and later is distributed with BSD_AUTH enabled. The SKEY and BSD_AUTH options are not enabled by default in many distributions. However, if these options are explicitly enabled, that build of OpenSSH may be vulnerable. I just had a look at openssh-3.0.2p1/debian/rules (3.0.2p1 is included with woody, before applying woody/updates: ./configure --prefix=/usr --sysconfdir=/etc/ssh --libexecdir=/usr/lib --mandir=/usr/share/man --with-tcp-wrappers --with-xauth=/usr/bin/X11/xauth --with-rsh=/usr/bin/rsh --with-default-path=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin --disable-suid-ssh --with-pam --with-4in6 --with-ipv4-default And ./configure --help says: --with-skey[=PATH] Enable S/Key support (optionally in PATH) So I'd assume S/Key is not included in Woody's 3.0.2p1 .deb. (I'm not familiar with package building in Debian, so I may be wrong.) If it really isn't all the hoopla was in vain. Thank you, Theo. I scrapped OpenBSD because of him. He has confirmed my opinion. Try to avoid anything contaminated by Theo de Raadt. I've spent several hours updating left and right, and now this? How shall I justify this to my client? I can't really charge for falling for Theo. Seems I took a firm stand and bent over for him. Lupe Christoph -- | [EMAIL PROTECTED] | http://www.lupe-christoph.de/ | | I have challenged the entire ISO-9000 quality assurance team to a | | Bat-Leth contest on the holodeck. They will not concern us again. | | http://public.logica.com/~stepneys/joke/klingon.htm| -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PermitRootLogin enabled by default
On Wed, Jun 26, 2002 at 02:11:00PM +0200, InfoEmergencias - Luis Gómez wrote: Hi all Messing up with sshd_config for all the privsep stuff, I've noticed that PermitRootLogin was set to yes in my three woody boxes. I usually consider this a problem (although it has been my fault - i should have checked and noticed this much time ago). What do you think of this? Not sure if you've seen this, but the maintainer offers an explanation in /usr/share/doc/ssh/README.Debian.gz Rob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
unsubscribe
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
openssh packages not vulnerable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 So as it turns out, AFAIK, none of the versions of OpenSSH in Debian were actually vulnerable to the exploit found by ISS and reported in DSA-134 Potato wasn't vulnerable because it is SSH1 only, and the problem lies in the ChallengeResponseAuthentication feature that only exists in the SSH2 protocol. Also in order to be vulnerable, either S/KEY or BSD_AUTH authentication mechanism needed to be enabled at compile time. The woody/sid packages do not enable either of these features. So what it all boils down to is that at no time was Debian vulnerable to this problem. I'm curious what recourse Debian is planning to take now? Perhaps removing the buggy OpenSSH 3.3 packages off of security.debian.org so people don't upgrade to it since it's not at all necessary and it will only cause problems like screwing up compression and pam. - -- Paul Baker They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin, 1759 GPG Key: http://homepage.mac.com/pauljbaker/public.asc -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (Darwin) Comment: For info see http://www.gnupg.org iD8DBQE9GheLoxmRVfL3nlsRAmM4AJ9mBv0mgZhEqW/Duzoj5SUQw4UewACeICe+ I6wH9uksQP9RJMpZk5YNqQc= =jknM -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: openssh packages not vulnerable
On Wed, Jun 26, 2002 at 02:35:21PM -0500, Paul Baker wrote: I'm curious what recourse Debian is planning to take now? Perhaps removing the buggy OpenSSH 3.3 packages off of security.debian.org so people don't upgrade to it since it's not at all necessary and it will only cause problems like screwing up compression and pam. And does anyone have any advice for people in my situation? Yesterday we upgraded 60some Debian 2.2 boxes to the new 3.3 packages. I would actualy like to have 3.4 packages. But should I just downgrade to what we had before? Thanks :) -- -tcole -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unsubscribe
This won't work. Have you noticed how EVERY MESSAGE says exactly how to do it, and how you didn't do that? You need to sent the message to [EMAIL PROTECTED] On Wed, Jun 26, 2002 at 09:34:09PM +0200, [EMAIL PROTECTED] wrote: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- John Goerzen [EMAIL PROTECTED]GPG: 0x8A1D9A1Fwww.complete.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: openssh packages not vulnerable
On Wed, 26 Jun 2002, Paul Baker wrote: I'm curious what recourse Debian is planning to take now? Perhaps removing the buggy OpenSSH 3.3 packages off of security.debian.org so people don't upgrade to it since it's not at all necessary and it will only cause problems like screwing up compression and pam. Even worse, on 2.0.x kernels PrivilegeSeparation doesn't work, rendinging sshd useless for interactive sessions or make it vurneble is you disable it. [RicV] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: openssh packages not vulnerable
On Wednesday, June 26, 2002, at 03:50 PM, Richard wrote: Even worse, on 2.0.x kernels PrivilegeSeparation doesn't work, rendinging sshd useless for interactive sessions or make it vurneble is you disable it. All debian versions of ssh packages are not vulnerable, AFAIK. I'm hoping the security team will make an official announcement. -- Paul Baker They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin, 1759 GPG Key: http://homepage.mac.com/pauljbaker/public.asc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PermitRootLogin enabled by default
That's how monkey.org got taken over--they SCREENed a su, and the attacker reattached it after getting as user via EPIC... On 26 Jun 2002, Christian Egli wrote: Simon Kirby [EMAIL PROTECTED] writes: Using su root later is worse than just logging in as root with a key. I cannot understand why using su root later would be worse. Can you enlighten me? -- FINE, I take it back: UNfuck you! Who is John Galt? [EMAIL PROTECTED], that's who! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PermitRootLogin enabled by default
On Wed, Jun 26, 2002 at 02:11:00PM +0200, InfoEmergencias - Luis Gómez wrote: Hi all Messing up with sshd_config for all the privsep stuff, I've noticed that PermitRootLogin was set to yes in my three woody boxes. I usually consider this a problem (although it has been my fault - i should have checked and noticed this much time ago). What do you think of this? IMHO, we'd better set it to no. I always thought it was much better. Is there any landscape in which you may want to allow direct root login to your host? Not IMO. I thank my lucky stars every day that it was decided to allow root logins by default. I have 194 Debian boxes to look after. I have ssh identity keys setup. I can't go login to every box individually and run sudo or su every time I want to change something. I need to automate it, and I need to touch them all at once. If it did default to off then I would have to carefully change that every single time I upgrade ssh packages, or roll my own ssh packages. Allowing root logins is such a huge convenience when you have many machines that its really a must. And when you only have a few machines its easy enough to go to each one and disable it. -- -tcole -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PermitRootLogin enabled by default
hi all if an attacker got in ... as a user game over... they got in ??? - question is what damage can they do as user ... if an attacker get in the same way as root... game is really over... as they now have complete control of yoru machine.. - i prefer to disallow root logins... ( assumption in the above is that they can get in thru an existing ( vulnerability .. either as root or a user .. -- patch the original vulnerability fix it first ... worry about the follow-me around folks later ... ( like those in the van outside your home/office listening ( to the wireless connections... c ya alvin On Wed, 26 Jun 2002, John Galt wrote: That's how monkey.org got taken over--they SCREENed a su, and the attacker reattached it after getting as user via EPIC... On 26 Jun 2002, Christian Egli wrote: Simon Kirby [EMAIL PROTECTED] writes: Using su root later is worse than just logging in as root with a key. I cannot understand why using su root later would be worse. Can you enlighten me? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
FW: ISS Advisory: OpenSSH Remote Challenge Vulnerability
-Original Message- From: X-Force [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 26, 2002 9:56 PM To: bugtraq@securityfocus.com Subject: ISS Advisory: OpenSSH Remote Challenge Vulnerability -BEGIN PGP SIGNED MESSAGE- Internet Security Systems Security Advisory June 26, 2002 OpenSSH Remote Challenge Vulnerability Synopsis: ISS X-Force has discovered a serious vulnerability in the default installation of OpenSSH on the OpenBSD operating system. OpenSSH is a free version of the SSH (Secure Shell) communications suite and is used as a secure replacement for protocols such as Telnet, Rlogin, Rsh, and Ftp. OpenSSH employs end-to-end encryption (including all passwords) and is resistant to network monitoring, eavesdropping, and connection hijacking attacks. X-Force is aware of active exploit development for this vulnerability. Impact: OpenBSD, FreeBSD-Current, and other OpenSSH implementations may be vulnerable to a remote, superuser compromise. Affected Versions: OpenBSD 3.0 OpenBSD 3.1 FreeBSD-Current OpenSSH 3.0-3.2.3 OpenSSH version 3.3 implements privilege separation which mitigates the risk of a superuser compromise. Prior to the release of this advisory, ISS and OpenBSD encouraged all OpenSSH users to upgrade to version 3.3. Versions of FreeBSD-Current built between March 18, 2002 and June 23, 2002 are vulnerable to remote superuser compromise. Privilege separation was implemented in FreeBSD-Current on June 23, 2002. Note: OpenSSH is included in many operating system distributions, networking equipment, and security appliances. Refer to the following address for information about vendors that implement OpenSSH: http://www.openssh.com/users.html Description: A vulnerability exists within the challenge-response authentication mechanism in the OpenSSH daemon (sshd). This mechanism, part of the SSH2 protocol, verifies a user's identity by generating a challenge and forcing the user to supply a number of responses. It is possible for a remote attacker to send a specially-crafted reply that triggers an overflow. This can result in a remote denial of service attack on the OpenSSH daemon or a complete remote compromise. The OpenSSH daemon runs with superuser privilege, so remote attackers can gain superuser access by exploiting this vulnerability. OpenSSH supports the SKEY and BSD_AUTH authentication options. These are compile-time options. At least one of these options must be enabled before the OpenSSH binaries are compiled for the vulnerable condition to be present. OpenBSD 3.0 and later is distributed with BSD_AUTH enabled. The SKEY and BSD_AUTH options are not enabled by default in many distributions. However, if these options are explicitly enabled, that build of OpenSSH may be vulnerable. Recommendations: Internet Scanner X-Press Update 6.13 includes a check, OpenSshRunning, to detect potentially vulnerable installations of OpenSSH. XPU 6.13 is available from the ISS Download Center at: http://www.iss.net/download. For questions about downloading and installing this XPU, email [EMAIL PROTECTED] ISS X-Force recommends that system administrators disable unused OpenSSH authentication mechanisms. Administrators can remove this vulnerability by disabling the Challenge-Response authentication parameter within the OpenSSH daemon configuration file. This filename and path is typically: /etc/ssh/sshd_config. To disable this parameter, locate the corresponding line and change it to the line below: ChallengeResponseAuthentication no The sshd process must be restarted for this change to take effect. This workaround will permanently remove the vulnerability. X-Force recommends that administrators upgrade to OpenSSH version 3.4 immediately. This version implements privilege separation, contains a patch to block this vulnerability, and contains many additional pro- active security fixes. Privilege separation was designed to limit exposure to known and unknown vulnerabilities. Visit http://www.openssh.com for more information. Additional Information: ISS X-Force and Black Hat consulting will host a presentation titled, Professional Source Code Auditing at Black Hat Briefings USA 2002. The presentation will explore advanced source code auditing techniques as well as secure development best-practices. Please refer to http://www.blackhat.com and http://www.blackhat.com/html/bh-usa-02/bh-usa-02-speakers.html#Dowd for more information. Credits: The vulnerability described in this advisory was discovered and researched by Mark Dowd of the ISS X-Force. ISS would like to thank Theo de Raadt of the OpenBSD Project for his assistance with this advisory. __ About Internet Security Systems (ISS) Founded in 1994, Internet Security Systems (ISS) (Nasdaq: ISSX) is a pioneer and world leader in software and services that protect critical online resources from an ever-changing spectrum of threats and misuse. Internet Security Systems is headquartered in Atlanta, GA, with additional
Re: PermitRootLogin enabled by default
hi ya in order to update 10, 100 boxes ... with new setof changes.. you do NOT need to login into any of um ... many different ways to update each target box based on some master distribution server -- you do want to test the updates in a test farm before it goes out to production and protect that master server from foul play ( lots of sanity checking ) -- rsync, apt-get, custom-update.pl, lots of ways to update 10 or 100 or 1,000 servers once master distribution server is updated - am assuming that automated updates via cron is acceptable ( i use a custom update script of only files i allow to be changed ( based on a master server -- cant see wanting to logging into 100 or 1000 machines manually.. which means either the passwd is written down... or that there's an algorithm to its passwd ... ( i think using keys is bad... imho... if one machine is hacked... ( than they can log into all the rest of um with no effort... - guess its whatever one feels comfy with... fun stuff... :-) c ya alvin On Wed, 26 Jun 2002, Travis Cole wrote: On Wed, Jun 26, 2002 at 02:11:00PM +0200, InfoEmergencias - Luis Gómez wrote: Hi all Messing up with sshd_config for all the privsep stuff, I've noticed that PermitRootLogin was set to yes in my three woody boxes. I usually consider this a problem (although it has been my fault - i should have checked and noticed this much time ago). What do you think of this? IMHO, we'd better set it to no. I always thought it was much better. Is there any landscape in which you may want to allow direct root login to your host? Not IMO. I thank my lucky stars every day that it was decided to allow root logins by default. I have 194 Debian boxes to look after. I have ssh identity keys setup. I can't go login to every box individually and run sudo or su every time I want to change something. I need to automate it, and I need to touch them all at once. If it did default to off then I would have to carefully change that every single time I upgrade ssh packages, or roll my own ssh packages. Allowing root logins is such a huge convenience when you have many machines that its really a must. And when you only have a few machines its easy enough to go to each one and disable it. -- -tcole -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: PermitRootLogin enabled by default
Alvin, If the cracker can get in as a user, it's merely a matter of time before they can worm their way into becoming root. Defenses against this are difficult, the NSA version SELinux deliberately places great restrictions on user abilities to try to prevent just such things. But I don't think there is any certain way to prevent a user from gaining root access if they are capable and determined. Layered defenses are best, of course. Network firewall (or packet filtering), restricted service offering (no fingerd, no telnetd, etc), then strong authentication for login, then restricted access to root. Like you, I do not prefer to allow direct root logins so that an attacker must overcome each barrier in turn. One of my favorite features of Debian is being able to go through the packages at install time and un-select such things as fingerd and telnetd, so that the services never exist on the server. Curt- From: Alvin Oga [mailto:[EMAIL PROTECTED] hi all if an attacker got in ... as a user game over... they got in ??? - question is what damage can they do as user ... if an attacker get in the same way as root... game is really over... as they now have complete control of yoru machine.. - i prefer to disallow root logins... ( assumption in the above is that they can get in thru an existing ( vulnerability .. either as root or a user .. -- patch the original vulnerability fix it first ... worry about the follow-me around folks later ... ( like those in the van outside your home/office listening ( to the wireless connections... c ya alvin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PermitRootLogin enabled by default
On Wed, 26 Jun 2002, Alvin Oga wrote: hi all if an attacker got in ... as a user game over... they got in ??? - question is what damage can they do as user ... that's what happened--the EPIC hole gave user. monkey.org (Dug Song) was using standard security practice at that point, it's just for convenience's sake, the user had a few things screened, including a rootshell, probably because of the traditional Conventional Wisdom of not permitting any remote logins of root. I find this kind of ironic in another sense, as Dug Song is the author of a Man in the Middle tool that works against older SSHes if an attacker get in the same way as root... game is really over... as they now have complete control of yoru machine.. - i prefer to disallow root logins... ( assumption in the above is that they can get in thru an existing ( vulnerability .. either as root or a user .. -- patch the original vulnerability fix it first ... worry about the follow-me around folks later ... ( like those in the van outside your home/office listening ( to the wireless connections... This wisdom is where things start to fall flat. The only successful security approach is layered--don't run unnecessary services, patch things immediately, use strong authentication wherever possible, and maintain strict separation of privileges via ACLs, capabilities, or other methods. other layers can include external things like IPSEC, switched networks, firewalls, and such. The most obvious rule here is don't rely on any one layer. Your above statement really relies on the patch vulnerabilities layer, which means you violated the obvious rule. c ya alvin On Wed, 26 Jun 2002, John Galt wrote: That's how monkey.org got taken over--they SCREENed a su, and the attacker reattached it after getting as user via EPIC... On 26 Jun 2002, Christian Egli wrote: Simon Kirby [EMAIL PROTECTED] writes: Using su root later is worse than just logging in as root with a key. I cannot understand why using su root later would be worse. Can you enlighten me? -- FINE, I take it back: UNfuck you! Who is John Galt? [EMAIL PROTECTED], that's who! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PermitRootLogin enabled by default
Travis Cole [EMAIL PROTECTED] writes: On Wed, Jun 26, 2002 at 02:11:00PM +0200, InfoEmergencias - Luis Gómez wrote: Hi all Messing up with sshd_config for all the privsep stuff, I've noticed that PermitRootLogin was set to yes in my three woody boxes. I usually consider this a problem (although it has been my fault - i should have checked and noticed this much time ago). What do you think of this? IMHO, we'd better set it to no. I always thought it was much better. Is there any landscape in which you may want to allow direct root login to your host? I thank my lucky stars every day that it was decided to allow root logins by default. If it did default to off then I would have to carefully change that every single time I upgrade ssh packages, or roll my own ssh packages. Huh? If an upgrade clobbers your configuration without asking you for permission that is a bug. File a bug report. Quoting from debian-policy 11.7.3 Behavior Configuration file handling must conform to the following behavior: * local changes must be preserved during a package upgrade, and * configuration files must be preserved when the package is re- moved, and only deleted when the package is purged. -- Olaf MeeuwissenEPSON KOWA Corporation, CID GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 LPIC-2 -- I hack, therefore I am -- BOFH -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DSA-134-1
El mar, 25-06-2002 a las 12:40, Robert van der Meulen escribió: and disclosure is only done when it doesn't affect openbsd (or the '5 years without..' line on openbsd.org). You'll love this one: One remote hole in the default install, in nearly 6 years! Great X'DD Depending on the language you see their web on, it may or may not have already changed... Luis -- Luis Gómez Miralles InfoEmergencias - Technical Department Phone (+34) 654 24 01 34 Fax (+34) 963 49 31 80 [EMAIL PROTECTED] PGP Public Key available at http://www.infoemergencias.com/lgomez.asc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PermitRootLogin enabled by default - yuppers
hi ya john On Wed, 26 Jun 2002, John Galt wrote: On Wed, 26 Jun 2002, Alvin Oga wrote: if an attacker got in ... as a user game over... they got in ??? - question is what damage can they do as user ... that's what happened--the EPIC hole gave user. monkey.org (Dug Song) was using standard security practice at that point, it's just for convenience's sake, the user had a few things screened, including a rootshell, probably because of the traditional Conventional Wisdom of not permitting any remote logins of root. I find this kind of ironic in another sense, as Dug Song is the author of a Man in the Middle tool that works against older SSHes think some folks are better targets ( or rather a more visible target ) than relatively anonymous machines at home on at dsl or att cable ??? if an attacker get in the same way as root... game is really over... as they now have complete control of yoru machine.. - i prefer to disallow root logins... ( assumption in the above is that they can get in thru an existing ( vulnerability .. either as root or a user .. -- patch the original vulnerability fix it first ... worry about the follow-me around folks later ... ( like those in the van outside your home/office listening ( to the wireless connections... humm .. bad choice of words ... lots of places to fix vulnerabilities not just patching apps... This wisdom is where things start to fall flat. The only successful security approach is layered--don't run unnecessary services, patch things immediately, use strong authentication wherever possible, and maintain strict separation of privileges via ACLs, capabilities, or other methods. yupp.. more the merrier ... wish i can play more with different stuff for experimenting and watching what happens other layers can include external things like IPSEC, switched networks, firewalls, and such. The most obvious rule here is don't rely on any one layer. Your above statement really relies on the patch vulnerabilities layer, which means you violated the obvious rule. wasnt meant to violate the obvious rule...but yes... more things and more layers... mroe bends.. more curves.. more traps the merrier .. which requires more time too and more $$ too ... i like to split all that up into...per their budget... - 5 minute security precautions.. - 5 hr security precautions.. good enuff for most ... - 5 days security precautions.. better for most ... - 5 weeks ... hummm...type slow and explain a lot to them ?? - but no matter which ...its always ongoing... job security !! until you lose one big battle with one good [cr/h]acker... have fun alvin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
