Security update for Debian Testing - 2008-08-29
This automatic mail gives an overview over security issues that were recently fixed in Debian Testing. The majority of fixed packages migrate to testing from unstable. If this would take too long, fixed packages are uploaded to the testing-security repository instead. It can also happen that vulnerable packages are removed from Debian testing. DTSA: = The following issues have been fixed by uploads to testing-security: r-base 2.7.1-1+lenny1: DTSA-162-1: r-base - symlink attack no CVE yet : r-base: insecure temp file http://bugs.debian.org/496418 samba 2:3.2.1-1+lenny1: DTSA-161-1: samba - privilege escalation CVE-2008-3789: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3789 http://bugs.debian.org/496073 Migrated from unstable: === awstats 6.7.dfsg-5: CVE-2008-3714: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3714 linux-2.6 2.6.26-3: CVE-2007-6712: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6712 CVE-2008-2372: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2372 CVE-2008-2750: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2750 CVE-2008-3496: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3496 CVE-2008-3534: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3534 CVE-2008-3535: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3535 qemu 0.9.1-6: no CVE yet : qemu: insecure temp file http://bugs.debian.org/496394 rancid 2.3.2~a8-2: no CVE yet : rancid: insecure temp file http://bugs.debian.org/496426 realtimebattle 1.0.8-8: no CVE yet : realtimebattle: insecure temp file http://bugs.debian.org/496385 sng 1.0.2-6: no CVE yet : sng: insecure temp file http://bugs.debian.org/496407 xmcd 2.6-21: no CVE yet : xmcd: insecure temp file http://bugs.debian.org/496416 How to update: -- Make sure the line deb http://security.debian.org lenny/updates main contrib non-free is present in your /etc/apt/sources.list. Of course, you also need the line pointing to your normal lenny mirror. You can use aptitude update aptitude dist-upgrade to install the updates. More information: - More information about which security issues affect Debian can be found in the security tracker: http://security-tracker.debian.net/tracker/ A list of all known unfixed security issues is at http://security-tracker.debian.net/tracker/status/release/testing -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Fwd: Password leaks are security holes
Hi Nico! Let's keep debian-security in the discussion to see what others have to say about this. Technically I agree with you when you say that people shouldn't enter anything but their usernames at the login prompt, but the fact is that people (like me and the bug submitter for example) *do* enter their passwords there from time to time. People make mistakes, and this is not an uncommon one. Security shouldn't be based on nobody ever doing more or less common mistakes. Regards //Johan -- Forwarded message -- From: Nico Golde [EMAIL PROTECTED] Date: 2008/8/27 Subject: Re: Password leaks are security holes To: Johan Walles [EMAIL PROTECTED] Kopia: [EMAIL PROTECTED], [EMAIL PROTECTED] Hi Johan, * Johan Walles [EMAIL PROTECTED] [2008-08-27 22:26]: severity 311772 critical tag 311772 + security thanks When users' clear text passwords are logged, that's a security hole. Setting severity to critical since this bug introduces a security hole on systems where you install the package. Quote is from the definition of the critical severity at http://www.debian.org/Bugs/Developer#severities. No its not, if you edit your credit card number as a user name this is also not the applications fault. makes unrelated software on the system (or the whole system) break, or causes serious data loss, or introduces a security hole on systems where you install the package. This doesn't say anything about users not being able to use the software in a proper way. Cheers Nico -- Nico Golde - http://www.ngolde.de - [EMAIL PROTECTED] - GPG: 0x73647CFF For security reasons, all text in this mail is double-rot13 encrypted. pgpGb2l85VqRr.pgp Description: PGP signature
Re: Fwd: Password leaks are security holes
Johan Walles wrote: Hi Nico! Let's keep debian-security in the discussion to see what others have to say about this. Technically I agree with you when you say that people shouldn't enter anything but their usernames at the login prompt, but the fact is that people (like me and the bug submitter for example) *do* enter their passwords there from time to time. People make mistakes, and this is not an uncommon one. Security shouldn't be based on nobody ever doing more or less common mistakes. auth.log was invented for this reason, and separated to standard log: it should be readable only by root, because users do errors. Anyway root already has the capability to view passwords (i.e. by installing alternate login programs, sniffing tty, ...) So auth.log should log usernames, so that users don't do wrong assumption that password are not accessible by root! ciao cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Fwd: Password leaks are security holes
--On Thursday, August 28, 2008 09:03:05 +0200 Johan Walles [EMAIL PROTECTED] wrote: Let's keep debian-security in the discussion to see what others have to say about this. you try to solve a non-technical problem in a technical way. Dirk -- [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Fwd: Password leaks are security holes
Hi Johan, * Johan Walles [EMAIL PROTECTED] [2008-08-28 11:46]: Let's keep debian-security in the discussion to see what others have to say about this. Technically I agree with you when you say that people shouldn't enter anything but their usernames at the login prompt, but the fact is that people (like me and the bug submitter for example) *do* enter their passwords there from time to time. People make mistakes, and this is not an uncommon one. Maybe this is the case but that's why this file is only readable for root and the adm group. So if an attacker is able to read this file you have way more problems as he wouldn't need to check the auth log for user errors but could just trace the login process, crack shadow, write a custom pam module or something similar to get your login credentials. Security shouldn't be based on nobody ever doing more or less common mistakes. See above. Cheers Nico -- Nico Golde - http://www.ngolde.de - [EMAIL PROTECTED] - GPG: 0x73647CFF For security reasons, all text in this mail is double-rot13 encrypted. pgp0KEMRDZzNA.pgp Description: PGP signature
Re: Fwd: Password leaks are security holes
2008/8/28 Giacomo A. Catenazzi [EMAIL PROTECTED]: Johan Walles wrote: Security shouldn't be based on nobody ever doing more or less common mistakes. auth.log was invented for this reason, and separated to standard log: it should be readable only by root, because users do errors. It's readable by anybody with physical access to the hardware. Hard disks get stolen all the time [1], and on publicly accessible machines it's often possible to boot in runlevel 1 or from something other than the hard disk and access any files you like. That's why the passwords in /etc/shadow are all hashed, rather than just being chmodded. Anyway root already has the capability to view passwords (i.e. by installing alternate login programs, sniffing tty, ...) That doesn't mean Debian should *help* root doing that in a default install. Security by default, anybody? So auth.log should log usernames, so that users don't do wrong assumption that password are not accessible by root! I can see a point in logging *valid* usernames. Logging invalid usernames (which aren't unlikely to actually be passwords) is a security risk. Cheers //Johan [1] - http://www.finfacts.ie/irishfinancenews/article_1014326.shtml -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Fwd: Password leaks are security holes
Hi Johan, * Johan Walles [EMAIL PROTECTED] [2008-08-28 13:14]: 2008/8/28 Giacomo A. Catenazzi [EMAIL PROTECTED]: [...] So auth.log should log usernames, so that users don't do wrong assumption that password are not accessible by root! I can see a point in logging *valid* usernames. Logging invalid usernames (which aren't unlikely to actually be passwords) is a security risk. How would you determine valid and invalid ones? A user name that is considered valid could still be a password. Cheers Nico -- Nico Golde - http://www.ngolde.de - [EMAIL PROTECTED] - GPG: 0x73647CFF For security reasons, all text in this mail is double-rot13 encrypted. pgpaoQ2dAQQFf.pgp Description: PGP signature
Re: Fwd: Password leaks are security holes
On Thu, 28 Aug 2008, Johan Walles wrote: 2008/8/28 Giacomo A. Catenazzi [EMAIL PROTECTED]: Johan Walles wrote: Security shouldn't be based on nobody ever doing more or less common mistakes. auth.log was invented for this reason, and separated to standard log: it should be readable only by root, because users do errors. It's readable by anybody with physical access to the hardware. Hard disks get stolen all the time [1], and on publicly accessible machines it's often possible to boot in runlevel 1 or from something other than the hard disk and access any files you like. That's why the passwords in /etc/shadow are all hashed, rather than just being chmodded. If you are that worried about physical hard drive security why don't you just run on a Live-CD? Anyway root already has the capability to view passwords (i.e. by installing alternate login programs, sniffing tty, ...) That doesn't mean Debian should *help* root doing that in a default install. Security by default, anybody? Physical security is not part of the OS (maybe except the DRM stuff..) So auth.log should log usernames, so that users don't do wrong assumption that password are not accessible by root! I can see a point in logging *valid* usernames. Logging invalid usernames (which aren't unlikely to actually be passwords) is a security risk. And you do you figure out if you are under attack? When I see that someone is obviously trying default system usernames I know there is an attack going on, if I only see that there have been 10 invalid login requests this could also be the CEO coming back from his 2 month vacation... Common sense: If you have accidentally typed in your password on the login prompt, login immediately and change the password! We shouldn't encourage people to continue using possibly compromised passwords. If they compromise it, they are responsible to change it immediately or to get the account locked!! This should be in your (computer use) company policy. Regards, Achim -- Achim Dreyer|| http://www.adreyer.com/ Senior Unix Network Admin || RHCE, RHCA, CCSA, CCSE, CCNA Phone: +44 7756 948229 || CACert assurer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Fwd: Password leaks are security holes
Mark Brown wrote: On Thu, Aug 28, 2008 at 01:05:19PM +0200, Johan Walles wrote: 2008/8/28 Giacomo A. Catenazzi [EMAIL PROTECTED]: auth.log was invented for this reason, and separated to standard log: it should be readable only by root, because users do errors. It's readable by anybody with physical access to the hardware. Hard disks get stolen all the time [1], and on publicly accessible machines it's often possible to boot in runlevel 1 or from something other than the hard disk and access any files you like. That's why the passwords in /etc/shadow are all hashed, rather than just being chmodded. As alternative, you could redirect auth syslogd to /dev/null (or to a pipe that filter results). Note that the important data are still available in 'last' (wtmp, btmp). But I don't think that on normal cases (which sould be the Debian default) the security is decreased having misstyped password on auth.log ciao cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Fwd: Password leaks are security holes
This one time, at band camp, Johan Walles said: 2008/8/28 Giacomo A. Catenazzi [EMAIL PROTECTED]: Johan Walles wrote: Security shouldn't be based on nobody ever doing more or less common mistakes. auth.log was invented for this reason, and separated to standard log: it should be readable only by root, because users do errors. It's readable by anybody with physical access to the hardware. Hard disks get stolen all the time [1], and on publicly accessible machines it's often possible to boot in runlevel 1 or from something other than the hard disk and access any files you like. That's why the passwords in /etc/shadow are all hashed, rather than just being chmodded. For a normal install, if someone has physical access, they have the machine. Pretending otherwise is a waste of time. Even though /etc/shadow is hashed, it's not all that difficult to run password crackers against it, and with a reasonable amount of CPU, it doesn't even take that long. If the hashes were completely safe, /etc/shadow could be 0644, right? Anyway root already has the capability to view passwords (i.e. by installing alternate login programs, sniffing tty, ...) That doesn't mean Debian should *help* root doing that in a default install. Security by default, anybody? We have that. We just don't (and can't) protect against someone stealing the disk and mounting it on their machine and rummaging through the filesystem. If you want that, use encrypted filesystems. Hopefully, you understand that that can't be the default, though. So auth.log should log usernames, so that users don't do wrong assumption that password are not accessible by root! I can see a point in logging *valid* usernames. Logging invalid usernames (which aren't unlikely to actually be passwords) is a security risk. I think it is also a very good way to notice a dictionary attack against a service, as opposed to a user screwing up their password. Arguing that users don't have to take any responsibility after they divulge their password doesn't impress me all that much. I'm not a maintainer for the package in question, but I certainly wouldn't make any changes based on that argument. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: Fwd: Password leaks are security holes
On Thu, Aug 28, 2008 at 01:05:19PM +0200, Johan Walles wrote: 2008/8/28 Giacomo A. Catenazzi [EMAIL PROTECTED]: auth.log was invented for this reason, and separated to standard log: it should be readable only by root, because users do errors. It's readable by anybody with physical access to the hardware. Hard disks get stolen all the time [1], and on publicly accessible machines it's often possible to boot in runlevel 1 or from something other than the hard disk and access any files you like. That's why the passwords in /etc/shadow are all hashed, rather than just being chmodded. If you take this argument to its logcal conclusion it affects pretty much any piece of software. If you accidentally type your password into a text editor it may save a backup file containing that password, for example. Type it into an IRC client by mistake and it'll become rather more public than you might anticipate. Once you start worrying about people with physical access to the machine there's a whole bunch of other issues to deal with - things like SSH private keys are also going to get exposed, for example. -- You grabbed my hand and we fell into it, like a daydream - or a fever. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Fwd: Password leaks are security holes
On 2008-08-28 13:05, Johan Walles wrote: It's readable by anybody with physical access to the hardware. If their have physical access to the hardware, auth.log would be my least worry. That doesn't mean Debian should *help* root doing that in a default install. Security by default, anybody? Yes. But I fail to see, that this is not the case here. I can see a point in logging *valid* usernames. Logging invalid usernames (which aren't unlikely to actually be passwords) is a security risk. Sometimes, a user thinks their username is valid, and the system thinks it is not. They call the system administrator and with the help of auth.log they can find out what the problem is. [1] - http://www.finfacts.ie/irishfinancenews/article_1014326.shtml It says Almost 4,000 Laptops lost or missing in Europe's major airports every week. Let's assume their disks are encrypted, which is very easy using the Debian Installer (since etch, IIRC?). Note: I certainly typed in accidently a password for a login name in the past and would not oppose a patch by you to (optionally!) not log user names. But I fail to see a real problem here. After all, most users make mistakes when it comes to e-mail (e.g. sending confidential information to the wrong person or even a publically archived mailing list etc.) Here I see much more potential for problems than auth.log. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#311772: Fwd: Password leaks are security holes
On Thu, Aug 28, 2008 at 09:36:41AM +0200, Giacomo A. Catenazzi wrote: auth.log was invented for this reason, and separated to standard log: it should be readable only by root, Then there is a bug in another package if this is what should be, because /var/log/auth.log is readable by group adm on all my systems. Anyway root already has the capability to view passwords (i.e. by installing alternate login programs, sniffing tty, ...) If the system uses MAC such as SELinux, this is not necessarily the case. We should design for such future technologies, and not expose passwords unnecessarily. On Thu, Aug 28, 2008 at 01:05:19PM +0200, Johan Walles wrote: auth.log was invented for this reason, and separated to standard log: it should be readable only by root, because users do errors. It's readable by anybody with physical access to the hardware. The logging we're talking about takes place in pam_unix. The normal password store for pam_unix is /etc/shadow, which is on the hard drive; if the user has physical access, they can run a password cracker against this file anyway and try to grab *all* user passwords, not just those of users who don't read before they type. (It's true that the passwords are not in /etc/shadow for systems using pam_unix together with NIS or NIS+, but I consider both NIS and NIS+ rather uninteresting cases.) So auth.log should log usernames, so that users don't do wrong assumption that password are not accessible by root! I can see a point in logging *valid* usernames. Logging invalid usernames (which aren't unlikely to actually be passwords) is a security risk. It provides information about username brute force attacks and other issues of concern to admins. On Thu, Aug 28, 2008 at 11:55:49AM +0200, Nico Golde wrote: Maybe this is the case but that's why this file is only readable for root and the adm group. So if an attacker is able to read this file you have way more problems as he wouldn't need to check the auth log for user errors but could just trace the login process, crack shadow, write a custom pam module or something similar to get your login credentials. No, that's not true. The only added permission the 'adm' group has on Debian is to be able to read log files; so this *does* expose passwords to users who wouldn't otherwise be able to get at them. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#311772: Fwd: Password leaks are security holes
On Thu, Aug 28, 2008 at 02:37:37PM -0700, Steve Langasek wrote: On Thu, Aug 28, 2008 at 09:36:41AM +0200, Giacomo A. Catenazzi wrote: auth.log was invented for this reason, and separated to standard log: it should be readable only by root, Then there is a bug in another package if this is what should be, because /var/log/auth.log is readable by group adm on all my systems. By default, nobody is in adm. Once upon a time (and still, on some systems) people made syslog world readable so people could diagnose their own problems. auth.log lets you keep syslog world readable without disclosing potentially sensitive authentication information. (It's true that the passwords are not in /etc/shadow for systems using pam_unix together with NIS or NIS+, but I consider both NIS and NIS+ rather uninteresting cases.) I'd say they're interesting, but increasingly uncommon. I can see a point in logging *valid* usernames. Logging invalid usernames (which aren't unlikely to actually be passwords) is a security risk. It provides information about username brute force attacks and other issues of concern to admins. Note that the pam_unix behavior is a bug, because it only logs some names of non-users; presumably it should log all or none. Whether this is a security bug is debatable (I think not). Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Fwd: Password leaks are security holes
Nico Golde un jour écrivit: Hi Johan, * Johan Walles [EMAIL PROTECTED] [2008-08-28 13:14]: 2008/8/28 Giacomo A. Catenazzi [EMAIL PROTECTED]: [...] So auth.log should log usernames, so that users don't do wrong assumption that password are not accessible by root! I can see a point in logging *valid* usernames. Logging invalid usernames (which aren't unlikely to actually be passwords) is a security risk. How would you determine valid and invalid ones? A user name that is considered valid could still be a password. If that is the case, then It is most likely a very bad password that someone could guess anyway, so that is a non-issue (except for the fact that the password should obviously be changed for a better one). Simon Valiquette -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#311772: Fwd: Password leaks are security holes
On Thu, Aug 28, 2008 at 02:37:37PM -0700, Steve Langasek wrote: On Thu, Aug 28, 2008 at 09:36:41AM +0200, Giacomo A. Catenazzi wrote: auth.log was invented for this reason, and separated to standard log: it should be readable only by root, Then there is a bug in another package if this is what should be, because /var/log/auth.log is readable by group adm on all my systems. I see the same (and a sarge box I checked also has that). I'm surprised enough by it that I think it must have changed at some point in the past. I don't think 'readable by group adm' is a reasonable default for /var/log/auth.log. It makes the adm group much less useful. Regards, Mark. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Password leaks are security holes
Hi, It is not often that I post but 1) Logging invalid usernames which can be used to detect all manor of attacks including dictionary username attacks and password brute force attacks. 2) As pointed out earlier the file is root only access. The argument that can be read if you physical access to the box. Physical access to the box gives you numerous methods of obtaining passwords including installing key loggers and stealing ssh keys. Once somebody has root on your box either through physical access or otherwise, I would be more concerned with all the other information they could have stolen which would give the game away. E.G. date of birth from emails or passwords to supposedly secure systems from stored emails. Going through a log of failed user attempts is going to be high hanging fruit. 3) If you are typing in your password as a username by mistake chances are you should change it immediately. It has probably been in the clear on the monitor at best and you could have been shoulder surfed. I guess you could be in a room with no one around but this should not be assumed. The username is also likely to be stored on remote machines for example in a bash history. 4) If this kind of error really concerns you move to a properly secure password system. Passwords are severely limited in many well documented ways. For a kickoff people can only remember so many password and therefor tend to write them down or use the same password for multiple accounts. Some sort of one time password system or certificate based system is probably the way to go. 5) A skilled administrator could use logging of failed user attempts as a way of detecting people entering a password as a username. This could then be used trigger for appropriate training or ensure that the password is changed. Example user contacts administrator to say they can't log into service administrator realizes that they are using the password instead of username. Administrator is able to fix issue and then either force or instruct user to change password. 6) It is an useful forensic feature. Clueless admin/user sets up server with rubbish password. Hacker/Cracker gets into account. Assuming Auth.log isn't cleaned (sometimes a bit assumption if they have got root) you can often establish vector of attack by fail logins. I agree it is a potential weakness but on the balance and attack vector but on balance I would rather have the feature there by default. Reasons 1 and 5,6 however make this a feature worth having on by default for me and I think the risks are very minor in comparison to the benefits. I could see the point of disabling this on default for home user who never checks logs but Debian used more as a server operating system (I know there are derivatives that are more workstation orientated). If you are using Debian as a Workstation chances are their are many easier places to steal passwords from such as application configuration files (e.g. gaim, mozilla and firefox). Regards Giles Johan Walles wrote: severity 311772 critical tag 311772 + security thanks When users' clear text passwords are logged, that's a security hole. Setting severity to critical since this bug introduces a security hole on systems where you install the package. Quote is from the definition of the critical severity at http://www.debian.org/Bugs/Developer#severities. Tagging with security because This bug describes a security problem in a package. Quote is from definition of security tag at http://www.debian.org/Bugs/Developer.en.html#tags. Regards //Johan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Password leaks are security holes
A. Dreyer un jour écrivit: On Thu, 28 Aug 2008, Johan Walles wrote: Anyway root already has the capability to view passwords (i.e. by installing alternate login programs, sniffing tty, ...) That's obviously true, but that doesn't cover the case when logs are copied to a second system with sysadmins that doesn't have access to the first server. And if someone use the standard 514 syslog port instead of using an SSL tunnel or the newer syslog-tls on port 601, well you get cleartext password on the wire (yes, people sometime make stupid mistakes). Personally, I would prefer never to see password stored in clear text anywhere, whatever the file permissions are. And If I really want to still see them, I certainly won't complain if all I have to do is make a small change to the default configuration file, telling the system that I know what I am doing. That doesn't mean Debian should *help* root doing that in a default install. Security by default, anybody? I think that everybody agrees that the default behaviour should be the most secure for most people, unless we have a very good reason to do otherwise. What some doesn't agree on is what is the most secure behaviour. I can see a point in logging *valid* usernames. Logging invalid usernames (which aren't unlikely to actually be passwords) is a security risk. And you do you figure out if you are under attack? Many failed connections, usually from the same IP with a few existing account in the lot, usually completelly unrelated account names (so easy to differentiate from someone that forgot the exact spelling of his/her account name). Realistically, there is very few cases were seeing the non existent account names is essential to detect an attack, and even when that happens, I am not sure that you would always realize that you are attacked. The very few companies that follows well enought their logs to be able to detect more attacks by allowing logging what is potentially a password are probably willing to change their configuration anyway. For most people, writting unknown account is a better security practice. When I see that someone is obviously trying default system usernames I know there is an attack going on, if I only see that there have been 10 invalid login requests this could also be the CEO coming back from his 2 month vacation... Would he types in 10 times in a row his password instead of his username? I don't believe It. If he just try to remember his password, then you will see 10 failed login attempt to his account before succeding or requesting a new password. If he tries to remember his username, then It is usually very easy to differentiate that from a real attack, even without seeing the username. Common sense: If you have accidentally typed in your password on the login prompt, login immediately and change the password! We shouldn't encourage people to continue using possibly compromised passwords. If they compromise it, they are responsible to change it immediately or to get the account locked!! They usually don't even understand that their password is potentially compromised. And if the password is not put in a log files, and that nobody saw their screen, they are actually right, which is good. And even if they know, most will hate to have to learn a new password, and avoid changing It if they can. This should be in your (computer use) company policy. A company policy that most people won't follows anyway. Just like asking people to use different password for each account. And if you configure the system to prevent them from using similar password for each account, or one similar to a past password, or if they are forced to change their password too often (possibly because they sometime put their password in the user field) then they start writting down the password somewhere they think nobody will find It, even if It is forbiden by policy. Policy won't change human nature, sorry. Simon Valiquette -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Please add Debian Security Advisory info for CVE-2008-2812
Hi, Please add Debian Security Advisory info for CVE-2008-2812. http://www.debian.org/security/2008/dsa-1630 and if there is no page for the vulnerability, please check http://lists.debian.org/debian-security-announce/ , then link to mail archive. Thanks. -- Regards, Hideki Yamane henrich @ debian.or.jp/iijmio-mail.jp http://wiki.debian.org/HidekiYamane pgpTzxsGtMLHd.pgp Description: PGP signature
DNS and cats: Password leaks are security holes
On 2008-08-28 20:40, Simon Valiquette wrote: That's obviously true, but that doesn't cover the case when logs are copied to a second system with sysadmins that doesn't have access to the first server. And if someone use the standard 514 syslog port instead of using an SSL tunnel or the newer syslog-tls on port 601, well you get cleartext password on the wire (yes, people sometime make stupid mistakes). I once typed a password accidently in address line of a web browser, which popped up in the wrong moment. This resulted in a DNS query for my password. I hereby declare it a security bug, that the web browser tries to resolve my password! :~) Personally, I would prefer never to see password stored in clear text anywhere, whatever the file permissions are. We're talking here about a password that has been typed accidently for other information. We're not talking about a regular password store. If the password is good, nobody will assume a password, but think, that a cat ran over the keyboard. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DNS and cats: Password leaks are security holes
W. Martin Borgert un jour écrivit: On 2008-08-28 20:40, Simon Valiquette wrote: That's obviously true, but that doesn't cover the case when logs are copied to a second system with sysadmins that doesn't have access to the first server. And if someone use the standard 514 syslog port instead of using an SSL tunnel or the newer syslog-tls on port 601, well you get cleartext password on the wire (yes, people sometime make stupid mistakes). I once typed a password accidently in address line of a web browser, which popped up in the wrong moment. This resulted in a DNS query for my password. I hereby declare it a security bug, that the web browser tries to resolve my password! :~) It could be worst: It could have googled for your password, and found many instances of It. ;o) Personally, I would prefer never to see password stored in clear text anywhere, whatever the file permissions are. We're talking here about a password that has been typed accidently for other information. We're not talking about a regular password store. If the password is good, nobody will assume a password, but think, that a cat ran over the keyboard. For the browser thing, yes maybe. For the syslog thing, when I see garbage as a username, my first reflex would be to immediately think that It is a password, and I expect It to be the password for one of the few next successful account login. The next thing I would do, is to try the same password for other systems, as people often reuse the same password, or a variation on the same password. So cracking one computer might helps the attacker to crack many other systems. Yes, people should probably change password if they mistakenly used It once as a username, and should use different passwords for different systems. But in the real world, laziness is very common. I personally believe that the risks of leaking passwords are usually much higher than the risk of seeing an attack unnoticed because It is written unknown for the username instead of what the user really typed in. In most cases, I don't believe It will affect much the probability of noticing the attack. And if you really want to get more information about the attacker, honeypots are your friends, on which It would be smart to log every usernames, whether they really exist or not. Simon Valiquette PS: I also almost forgot to say that there is tools like logcheck that will leak passwords over the net. For many systems, were confidentiality is not an issue, that kind of tools is very convenient and passwords are almost the only really valuable information that could be leaked in the logs. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
