Re: about bash and Debian Lenny
Carlos Alberto Lopez Perez un jour écrivit: Maybe your http client is unable to understand Content-Encoding: gzip ? I downloaded the files from the provided location with Links2 web browser. The file bash_3.2-4+deb5u1.dsc was a gzipped file. After decompressing it became standard .dsc file. I don't know what is wrong with your setup, but I'm not able to reproduce that. $ wget http://people.igalia.com/clopez/bash-shellshock-lenny/bash_3.2-4+deb5u1.dsc Of course you can't as you didn't even tried to reproduce it using the same application (here links2). That said, both links and links2 on Debian stable seems to work fine. As stated, it is probably an issue related with "Content-Encoding: gzip" or a user mistake. If it can be reproduced, it should probably be talked about on the links2 BTS page instead of here. In any case, bash_3.2-4+deb5u1.dsc is fine AFAIK. Simon Valiquette -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5432e22d.1040...@ieee.org
Re: RSA/DSA
Wim Bertels un jour écrivit: On vr, 2011-11-25 at 11:31 +, Florian Weimer wrote: * Wim Bertels: So why isn't it possible to choose one the longer keylengths for DSA? The original DSA standard explicitly required that key lengths did not exceed 1024 bits. Older OpenSSH versions implemented that standard. True, but in 2009 FIPS 186-3 officially increased the DSA maximum keylength to 3072 bits. The man page about ssh-keygen still talk about the old FIPS 186-2 standard even in OpenBSD 5.0, so perhaps I could ask them what are their plans about it. Perhaps they keep it just for backward compatibility reasons and want people to move away from DSA. For those interested, you can read the official NIST document on page 15 (actually the 25th page of this PDF document): http://csrc.nist.gov/publications/fips/fips186-3/fips_186-3.pdf tnx, i wonder then if using 1024 on squeeze (or lenny) is still secure? AFAIK, DSA and RSA 1024 are still not considered broken. But if you need to use a fingerprint that will need to be still valid for a lot more than 5 years, I would certainly avoid it. And I wouldn't use it at all for generating a new remote logging key. Actually, I wonder if we should remove completely the DSA host key in Debian unstable and just stick with RSA, which is now patent free and used by almost everyone. Except for backward compatibility, I see few reasons to still use DSA. I notice that openssl started supporting DSA 2048 years before it became part of the official standard, but OpenSSH still don't (and maybe won't). As a host key, I guess it is probably still secure enough for most people, but I see few reasons to still use DSA if you don't have to. As a remote logging key, I wouldn't use a DSA-1024 key as they tend to be used for much longer than originally planed. do u know if ssh can work without DSA, using only RSA? Yes it can. I started disabling DSA in sshd_config at least 3 years ago (because of the keylength) and never had any problem. What is important to know, is that DSA was used because RSA was patented. Once the patent expired in years 2000, OpenSSH quickly supported it (and I guess the few other implementation that didn't already). Also, it seems that the OpenSSH client first try RSA and fallback to DSA only if it is not supported by the server (or perhaps it just use the longest available key). Don't know about others implementation, but they are more than likely to default to RSA or not to support DSA at all. Unless you have to deal with very old systems (8+ years) that support only DSA (and are probably full of security issues anyway) I don't think you will have any problem. If you want to be sure, you can increase the verbosity of OpenSSH and check in the logs if any connection ever used something else than RSA. If after few months no host ever used DSA, you'll know you probably can disable it completely. Simon Valiquette -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ed546bd.8000...@ieee.org
Re: Recent libssl update.
Mike Mestnik un jour écrivit: It is usual to have to restart services to load security updates? Yes, but it is usually done automatically. There is usually no other simple way to make sure that a program is using the new version of a library. But the main services that use libssl like OpenSSH, Postfix and Apache are by default already automatically restarted if needed when libssl is updated. At least it is better than having to reboot the server, and in the case of Apache users won't notice it because old threads will stop only once currently openned connections are closed while new requests will be served by new threads using the new library. Is this something to be corrected or should I be diligent and restart services periodically? Periodically, no it is not necessary. Restarting a service is only needed after updating a library used by that service, but it is usually already done automatically, at least for the most common cases. That said, user's programs are usually not automatically restarted, but that's the same after any library update. So if for example you update a library used by Firefox (like libgnutls), you will have to restart it if you want to be sure it use the new version of the library. I hope that makes thing clearer. Simon Valiquette -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ec0b8ff.7090...@ieee.org
Re: how to send IP packets by myself
tantan un jour écrivit: Hello, to know someone from using a packet generator? tcpreplay allow you to send specific packets from a file, including invalid ones AFAIK. Since you can alter the packets, it can be useful for testing the application when receiving bad data like a string that is one bit too short or other limit conditions. There is some tricks to intercept the packets in the fly and mangle them a little before resending them. http://tcpreplay.synfin.net/trac/wiki/manual tcpcat can also sometime proves useful. If all you use is a tcp/ip connection and the protocol is text based, like SMTP, a script in Perl, Python or even some Shell script (note that in Debian, this is disabled by default in Bash) could be the easiest solution for you. I'd like to create packages in-house design, and then send it. The goal is to analyze communication between two partners, so down to the smallest possible Detail. So, you don't really want a packet generator. Here the good old tcpdump will be your friend. Snort might also be useful in some situation where there is many servers involved and you want to remove all regular packets and gets only the problematic ones. There is plenty of good tutorial for both. Simon -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: PGP key to use to contact the Security Team
Joey Schulze un jour écrivit: Simon Valiquette wrote: In the Securing Debian Manual, the key id to use to send an encrypted email to the security team is 363CCD95, but on the following link, it is F2E861A3 that is listed instead. http://www.debian.org/security/faq.en.html#contact Maybe the Securing Debian Manual is not up-to-date with regards to the security contact key? I know, but since both keys were still valids, there was nothing either to indicate that it was the FAQ page which was wrong. 1. Do both keys are still valid? You should use 0x/F2E861A3. Thank you, I will fix the Securing Debian Manual about it. 2. If the key F2E861A3 is legitimate (which I think it is because I have a trust path to it), wouldn't it makes sense to sign it with the old key as well? Or alternatively by 3 members of the security team instead of just one? "old key" would refer to 0x3682B5DF which expired on February 1st 2007 and is the predecessor to the current key. It would be kind of late to sign the current key with it only now, but it can make sense to sign the next key with F2E861A3 before it expire. Unless it is revoked, it would show quite clearly the intent and makes faking a new key much more difficult. Alternatively, announcing the new key once a year on debian-security in a signed email would do it, as we would be able to easily google for the key and check if it is legitimate. People writing documentation would also notice the change a lot more quickly. The idea is that it is actually too easy for a single person to fake a new key ID, and too difficult to checks its legitimacy as the only public reference to it was the security FAQ page. Another solution is to have 3 people from the security team signing the key, as that would increase enough the trustfulness of the key. Simon Valiquette -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
PGP key to use to contact the Security Team
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Hello, I am finishing the French translation of the Securing Debian Manual, and I noticed something about the key to use to contact the Debian Security Team. In the Securing Debian Manual, the key id to use to send an encrypted email to the security team is 363CCD95, but on the following link, it is F2E861A3 that is listed instead. http://www.debian.org/security/faq.en.html#contact http://pgpkeys.pca.dfn.de/pks/lookup?search=0xF2E861A3&op=vindex http://pgpkeys.pca.dfn.de/pks/lookup?search=0x363CCD95&op=vindex So far so good, but the old key seems to still be valid since it is not revoked, and Google find many references to it while Google find only one reference to F2E861A3, a key that is signed by only one person. So here are my questions: 1. Do both keys are still valid? 2. If the key F2E861A3 is legitimate (which I think it is because I have a trust path to it), wouldn't it makes sense to sign it with the old key as well? Or alternatively by 3 members of the security team instead of just one? 3. The key F2E861A3 claims to have been created on 2007-07-29 and is set to expire on 2009-02-18. So could someone clarify what will happens after it expire in six weeks? Will it be replaced by a new key, or will the expiration date simply be changed? 3. If the old key 363CCD95 is not used anymore, is there any reasons for not revoking it? Thank you in advance for the clarifications, Simon Valiquette -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Linux PPC) iEYEAREDAAYFAklYwvkACgkQJPE+P+aMAJIXxACfZaIjWuqVFsakCdobInLVGqKm OgoAmwcLp+cmGLJX7lyeVxnRKh28kMAQ =+FqI -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Root login
Roger Bumgarner un jour écrivit: I just tested this behavior on my Lenny/Sid workstation and Etch server... frightening indeed! Lenny does spit out an error whereas Etch still gives a password prompt. Well, It is not that bad as It is usualy only exploitable localy. But still certainly not the best behavior. Also, It allows to guess if some application have been installed without loggin in, because some application creates a user in /etc/passwd however, since this happens at the login shell, I'd be more concerned about a user booting a liveCD. I assume SSH still behaves correctly? can someone verify? It is all configured in PAM, and ssh use a different config file so It is not affected. To restore the original behaviour, just modify the file /etc/pam.d/login by replacing the following line by the second: #auth requisite pam_securetty.so authrequiredpam_securetty.so or even better (on a single line): auth [success=ok new_authtok_reqd=ok ignore=ignore auth_err=die service_err=die default=ignore] pam_securetty.so You can look at man pam.d (5) and pam_securetty to understand what It changes. With the Lenny behaviour, someone who attempt by mistake to login as root when using a tty (or equivalent) that has not been marked as trusted in /etc/securetty will be prevented to enter the root password (actually just strongly discouraged). With the old behaviour, he/she would still have been able to type in his password using a potentially untrusted channel, before seeing his login attempt being denied anyway. My guess is what they really wanted to do was something like the following: auth [success=ok new_authtok_reqd=ok ignore=ignore auth_err=die service_err=die default=ignore] pam_securetty.so I only made some quick tests by disabling one tty in securetty, so you should check It before trusting that It works as intended. Simon Valiquette -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: apt-get not upgrading kernel
Alexander Reichle-Schmehl un jour écrivit: >> I can see that CVE-2008-3272 and CVE-2008-3275 had already been fixed in DSA-1630-1, but can you confirm that the other CVE doesn't affect 2.6.18? Well... According to http://security-tracker.debian.net/tracker/source-package/linux-2.6 it isn't. The security tracker could be wrong. While useful, I don't trust It blindly. More specifically, can someone confirm that CVE-2008-3915 doesn't affect the 2.6.18 kernel series in Debian? If I believe this link, this bug is not limited to 2.6.24 in Etch-and-a-half. http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2008-3915 http://security-tracker.debian.net/tracker/CVE-2008-3915 list only 2.6.24 as affected. Looking your link, the first version they list is 2.6.19.4. So, yes, it pretty much looks to me, as if etch's 2.6.18 is not affected by this issue. Look better: 2.6.18 is listed, but as one of the last entries. I don't know why It is not listed in the same order, but It is true that It was easy to miss It. Also, even if you would have been right, It would still be possible that Debian added a patch backporting the security problem (or hiding/fixing the bug by pure luck). Checking for that bug is not very difficult, but checking for this bug and all the other one can be very time consumming and boring, which can explain some delay. Simon Valiquette -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: apt-get not upgrading kernel
Alexander Reichle-Schmehl un jour écrivit: Hi! * Kheng Teong Goh <[EMAIL PROTECTED]> [080912 04:21]: I have 2 system on slicehost running debian. apt-get update and apt-get upgrade has not been upgrading my kernel. It has been upgrading other packages. Kernel remains as : 2.6.18-xen #1 SMP Tue Feb 12 06:40:50 UTC 2008 x86_64 The latest kernel related DSA (1636) only affected the 2.6.24 kernel shipped with Etch-and-a-half. I can see that CVE-2008-3272 and CVE-2008-3275 had already been fixed in DSA-1630-1, but can you confirm that the other CVE doesn't affect 2.6.18? More specifically, can someone confirm that CVE-2008-3915 doesn't affect the 2.6.18 kernel series in Debian? If I believe this link, this bug is not limited to 2.6.24 in Etch-and-a-half. http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2008-3915 Simon Valiquette -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: apt-get not upgrading kernel
Kheng Teong Goh un jour écrivit: Hi! I have 2 system on slicehost running debian. apt-get update and apt-get upgrade has not been upgrading my kernel. It has been upgrading other packages. Kernel remains as : 2.6.18-xen #1 SMP Tue Feb 12 06:40:50 UTC 2008 x86_64 Is it something I am not doing right? Only the kernel 2.6.24 have been patched. I didn't check all the CVE, but It seems that all the security issues fixed today in 2.6.24 also affect the 2.6.18 kernels (mostly Xen and Vserver, but also many special kernel such as the one for PReP PowerPC machines). CVE Id(s) : CVE-2008-3272 CVE-2008-3275 CVE-2008-3276 CVE-2008-3526 CVE-2008-3534 CVE-2008-3535 CVE-2008-3792 CVE-2008-3915 Depending of how you use your server, and If you can trust the users on your system, maybe those bugs are not a very big liability for you. But I can't judge at your place. Hopefully, the security team will eventually release an update for the other kernel. If you can't wait, you can try to manualy patch your kernel for the security issues that concern you the most and recompile. Simon Valiquette -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Password leaks are security holes
Eduardo M KALINOWSKI un jour écrivit: Simon Valiquette wrote: 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. No password is stored in this case. User names (or whatever the user input as "user name") are. If the user types some other random thing instead of an user name, that doesn't make it a password, even if the random garbage happens to be a password. Pedantically, that's true. But a smart human will have no difficulties to guess that It is probably a password and guess the associated account name. And even if in this case the password gets stored (not as such, but as a mistakenly typed user name), it is by default hidden from view, unless the system administrator does something different, such as your syslog-over-network example. I already explained in a previous post how even if the logs are kept only on a single host and even if the logs are only root readable, that It can still helps compromising other systems. Anyway, I saw that the maintainer recognized It as a problem and marked the bug as confirmed, so I won't argue any more about It as I don't think I have anything useful to add. Simon Valiquette -- 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]
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]
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: Microsoft-IIS/6.0 serves up Debian... WTF!
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Jim Popovitch un jour écrivit: >> >> Yep this is lighttpd and it's mod_status. > > OK (if true), I still question the need for posing as IIS, and > therefore I question the mirror operator's > intent/reasons/capabilities/interests/ as well as security > capabilites. Are they playing around by posing as IIS. Is it meant > to deflect interest in a Linux box being on their network? What is > the reason behind masquerading as something they aren't? My best guess is that It is security by obscurity. Personnaly, I often configure mail servers to claim to be another mail server, running on a different operating system and with some ad hoc version number that seams reasonable. The idea is that script kiddies, and many other attackers, will waste time using attacks that have no chance of succeeding, giving you an opportunity to detect and block an attack before It really start. Except by buying you a bit of time, in practice It doesn't add much real security against a determined attacker, but It is very useful for honeypot. > > If they want to do this, fine. But should they continue to be in > rotation for ftp.us.debian.org? Personnaly, I would have chosen to impersonate another web server than IIS, but except for that I see no problem with what they have done. I don't see why you want them to be removed from ftp.us.debian.org, except that you don't like to see them lying about the server application and version they use, which is something done by a lot of people on production systems that directly face the Internet. Simon Valiquette -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (Linux PPC) iD8DBQFITE9qJPE+P+aMAJIRA5JpAKCtOVrvTPpcDw1/lxI7CV6oxoItDwCg9jvq kRg3a23JXWO5piDR5sl43Kc= =tHtZ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Accepted openssh-blacklist 0.3 (source all)
Kees Cook un jour écrivit: On Wed, May 21, 2008 at 07:07:34AM +0200, Vincent Bernat wrote: I could be mistaken, but prior to openssl breaking, ssh-keygen stopped allowing dsa 2048 keys, which means there wasn't a way to generate bad ones: It didn't before. At least not directly from ssh-keygen. It is so because It won't be standard compliant (the standard specify that DSA must be 1024 bits). I don't know if OpenSSH will accept longer keylength (some implementation will certainly refuse It). Personnally, in situation when I really care, I like to simply disable DSA from sshd_config and remove the shorter key from /etc/ssh/ $ ssh-keygen -t dsa -b 2048 DSA keys must be 1024 bits I think It is possible to generate them with openssl. It is normaly used to generate X.509 certficates, but I think you can also get It to generate keys in the proper format for SSH. In any case, It can generate 2048 DSA keys or even longer ones if needed. Look at those man pages and on Google. man openssl man dsaparam man gendsa Simon Valiquette -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [SECURITY] [DSA 1571-1] vulnerability of past SSH/SSL sessions
Micah Anderson un jour écrivit: * Simon Valiquette <[EMAIL PROTECTED]> [2008-05-14 16:36-0400]: In other words, if a vulnerable key have been involved, and if someone was able to intercept and save the encrypted data, he/she can now decipher It, whether It is passwords, ssh sessions, secure pop/smtp sessions, ssl tunnels or even database transactions. So you need to change every passwords at risk (bothersome, but relatively easy), but also consider that secure/confidential information, including credit card transactions or whatever, have been disclosed, which is a much bigger problem. SSH traffic cannot be compromised that way. Basically the encryption key used for the SSH session is *not* the host key nor the client key itself, but it is created on session initiation using a Diffie-Helman key exchange I know, and I though It was obvious in my email that I was aware of that. The problem is that, AFAIK, the encryption key generated for the session is also build by openssl. If the bug we talk about also affect DH, then I believe that the probable random number "a" and "b" could be limited to a much smaller group, and thus one could try to guess the shared session key "g exp(ab)" if the number of possibilities are small enough to make an exhaustive search. and the host/client keys are just used to verify the authenticity of the server. In other words, ssh sessions are not compromised just because an adversary has the host keys (unless a MITM is setup, in which case you need bot the host key and the authentication key to perform a mitm attack). I insisted on the case where *none* of the host key where vulnerable (my case on many systems), but one or two of the host involved used a vulnerable openssl library. So, this is a different problem. Generating good random number properly are difficult enough that I would expect them to came from the same function. I didn't have time to look at the code, and I would be more than happy to be proven wrong. Simon Valiquette -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [SECURITY] [DSA 1571-1] vulnerability of past SSH/SSL sessions
Affected keys include SSH keys [...] and session keys used > in SSL/TLS connections. It seems that people are insisting quite a lot on the bad keys, but what worry me a lot more is that, apparently and very logically, past ssh connections and any SSL session keys are to be considered compromised. In other words, if a vulnerable key have been involved, and if someone was able to intercept and save the encrypted data, he/she can now decipher It, whether It is passwords, ssh sessions, secure pop/smtp sessions, ssl tunnels or even database transactions. So you need to change every passwords at risk (bothersome, but relatively easy), but also consider that secure/confidential information, including credit card transactions or whatever, have been disclosed, which is a much bigger problem. I think that most security knowledgeable people understood that part. For the others, then It is good that you understand It clearly now. But what still bother me a bit, is in the case that both host keys are not vulnerable, but one of the openssl implementation involved was. For example, I have many host keys that have been generated from Slackware or OpenBSD, and which are much longer than the default, so clearly not vulnerable (at least, not vulnerable to this specific bug). But even in that case, if one of the system involved in a SSL transaction have a buggy version of openssl, I wonder if the session key might still be guessed. If the vulnerable host is A, then my understanding is that an attacker could guess "a" and "g exp(a)", so that if he can get either "b" or "g exp(b)", he can crack the session key. In other words, if host A and host B use a flawed openssl implementation, then the communication can be compromised even if both host keys are not vulnerable. Here are my questions: 1. If both host use a flawed openssl, but good host keys, about how much sessions keys the attacker will have to try? I expect that would be the square of the number of probable values for "a", but I have no idea of the number of probable values for a. 2. About how much time would It takes to break one session key, let say using a small setup with 8 pentium IV at 2GHz just to give an idea. My uneducated guess is that It could theorically takes significantly less than a week. 3. If only one of the computer involved have a flawed openssl, but none have a vulnerable host key, is It still practical to break the session key? If yes, about how long could It takes? The Diffie-Hellman algorithm is far in my memory, including the exact way It is used in setting up an SSL transaction. I think that the exchanged data are both signed *and* ciphered using RSA or DSA. If I am right, all the "public" data are exchanged using the public host keys, so if they are not vulnerable, maybe there is not enough information known to the attacker easily crack the session key, even if the session key have obviously been significantly weakened. And a last question that came to my mind: 4. During the session key creation, do there is still some entropy left from the clock, or something other than the process id? If you answered question 1, you can probably easily answer this one. I still need to change the passwords and host key of every possibly affected system (mostly done), but I would feel better by knowing exactly what to expect. Thank you, Simon Valiquette -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: securing server
Jean-Paul Lacquement un jour écrivit: Hi, I plan to secure my Debian stable (or testing if you say it's better) server. The followings daemon are installed : - proftpd - apache2 - ssh If you need to offer a public ftp access, and that you don't need all the features of proftpd, I would suggest you to use vsftpd instead. vsftpd is probably the most secure ftp server currently available, It is extremely easy to configure and also happens to be one of the most efficient ftp server. If you need authenticated connexions, as previously mentionned, sftp is probably your best solution, as the FTP protocol is inherently insecure. For the rest, I think people have already pointed out the most important packages and documentation, except maybe selinux (but that involve more work, and is probably only relevant once the other suggestions have been taken care of). Simon Valiquette -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Kernel upgrade for 3Ware Driver issues?
Rolf Kutz un jour écrivit: On 23/04/08 07:00 -0400, Michael Stone wrote: disk"--systems maintainence issue.) The end result of data security processes should lead you to backups or some other contingency plan, no shoving arbitrary software into stable because it scratches your itch. Instead of blowing the computer security horn because that horn happens to have resources attached to it, you should pursue the general systems maintenance horn because that's what this problem is. (The you here is plural, and this is an industry-wide problem.) Ack. But there should be a way to fix rc-bugs even after release. I fully agree that this bug doesn't deserve a security update, but I see no reason for not fixing in 4.0r4 what would normally be considered a release critical bug. Since there is not urgency to release, or security issues involved, It would be easy to publicly ask people to test the fix in order to get better testing. I my opinion, the only proper period to include those fix are when there is a new revision, or maybe before if there is another problem that already deserve a DSA and that the security team feels comfortable to include both fix at the same time. But there should be an official way to get major problems fixed when the risk of breaking somethings is low enough. Simon Valiquette -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [SECURITY] [DSA 1494-1] New linux-2.6 packages fix privilege escalation
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Florian Weimer un jour écrivit: > > Package: linux-2.6 > Vulnerability : missing access checks > Problem type : local > Debian-specific: no > CVE Id(s) : CVE-2008-0010 CVE-2008-0163 CVE-2008-0600 > In the vserver-enabled kernels, a missing access check on certain > symlinks in /proc enabled local attackers to access resources in other > vservers (CVE-2008-0163). > > For the stable distribution (etch), this problem has been fixed in > version 2.6.18.dfsg.1-18etch1. > > In addition to these fixes, this update also incorporates changes > from the upcoming point release of the stable distribution. > > The old stable distribution (sarge) is not affected by this problem. > > The unstable (sid) and testing distributions will be fixed soon. It seems that there is no update available for PowerPC and Sparc, and maybe other architectures as well. Do we have again the problems we had with security updates for PowerPC in August 2007? If the updates are known to be available only later, would It be possible to announce It in the advisory, as It is usually done? And maybe make a statement about It if an architecture is not affected (though It is obviously not the case here). Simon Valiquette http://gulus.USherbrooke.ca -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (Linux PPC) iD8DBQFHsNVRJPE+P+aMAJIRA9XjAKDBFjM1qF7Uoz69bWAqmShNgHr2vQCeJSTo 1fV9NossyFITd9IVkE5JtE8= =9dXH -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Firewall with woody
Jorge Escudero un jour écrivit: I have the Firewall with woody and I never had got any security problem. Is it risky to still using this version? For a firewall, you need to at least upgrade the kernel and patch + recompile ssh and libssl. More library update are also needed if you also care about local exploits. You also need to know what you are doing, because otherwise you could experience some problems. For example, if you are doing traffic shapping with /sbin/tc, you will need to patch iptable because of changes in kernel 2.4.20 (which means you need to read the kernel changelog before). You need to have a really good reason for not upgrading, and if you need to ask, then you probably don't have such a reason. There is a few production servers I still maintain with Woody and the latest 2.4 kernels with special patches. But It means I need to follow bugtraq and other mailing lists, sometime hand patch some programs or libraries and understand what I am doing. And I get money for spending time maintaining those systems. That said, I won't run a Woody firewall unless I am forced to. If the problem is the frequent 2.6 kernel updates, then Sarge also support the 2.4 kernel and could win you few months, but I doubt it is worth It in your case. Do I have to upgrade the version any time a new one is release? You could decide to upgrade to Sarge, and wait until Lenny is out to upgrade to Etch and so on, but Etch is much better than Sarge in my opinion and would go directly there. If you are paranoid, you will also want to activate SELinux. Simon Valiquette -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
missing security updates for powerpc
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Hello, On security.debian.org, there is no security update available for dovecot-common, postfix-policyd and rsync. On the other hand, there is a powerpc version for the latest DSA (lighttpd, which is ironically the only one I am not using between the 4 listed packages). I would like to know who is responsible for the powerpc security build, and makes sure he/she knows about the problem (and ideally heard a bit about what happened). I did notify debian-security yesterday, but very little seems to happens, except that postfix-policyd was released after without powerpc and without explication or notification of why. I had no problem recompiling them for my systems, and It seems to work fine, so It is not a build problem. For those that don't want to wait for the upgrade, here the simple procedure: sudo apt-get -Vu build-dep rsync sudo apt-get -Vu source --compile rsync dpkg -i rsync_2.6.9-2etch1_powerpc.deb At least, I was not forced to wait for support and could recompile or patch It myself, which would not have been possible with most closed source software :o) Simon Valiquette -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (Linux PPC) iD8DBQFG1jYiJPE+P+aMAJIRA9Q4AJ4oyJnbwGc9m95ZLv9YCE1/mvpwtACguv0v p4RliaZ9A/PbOhuauDyE0zQ= =amkj -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [DSA 1359-1] New dovecot packages fix directory traversal
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Simon Valiquette un jour écrivit: > > There is no updated packages for Debian Etch PowerPC, contrarily > to what is stated on the previous line. > > > In case sec.deb.org/dists/etch/updates/main/binary-powerpc/Packages.gz > would not have been up to date, I searched in the email for the direct > link to the rsync_2.6.9-2etch1_powerpc.deb file, but realized the > whole section was also missing in the advisory. > > Actually, the file have not been uploaded at all on security.debian.org > > > Is there again a problem with the build host or something? > I forgot to mention that the same problem existed with Dovecot, which is why I suspected a problem with the build host, or at least the upload to security.debian.org Simon Valiquette -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (Linux PPC) iD8DBQFG1HgCJPE+P+aMAJIRAw6rAKDIVRFGq1r8AHS2TpGHISjlE9cV0QCgzRp4 w6zvJGH56H9CPvOnmBcJBYw= =ceOE -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [DSA 1360-1] New rsync packages fix arbitrary code execution
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Steve Kemp un jour écrivit: > > Sebastian Krahmer discovered that rsync, a fast remote file copy > program, contains an off-by-one error which might allow remote > attackers to execute arbitary code via long directory names. > > For the stable distribution (etch), this problem has been fixed > in version 2.6.9-2etch1. > > Debian GNU/Linux 4.0 alias etch > - > > Stable updates are available for alpha, amd64, arm, hppa, i386, > ia64, mips, mipsel, powerpc, s390 and sparc. > There is no updated packages for Debian Etch PowerPC, contrarily to what is stated on the previous line. In case sec.deb.org/dists/etch/updates/main/binary-powerpc/Packages.gz would not have been up to date, I searched in the email for the direct link to the rsync_2.6.9-2etch1_powerpc.deb file, but realized the whole section was also missing in the advisory. Actually, the file have not been uploaded at all on security.debian.org Is there again a problem with the build host or something? Simon Valiquette -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (Linux PPC) iD8DBQFG1HZDJPE+P+aMAJIRAwJPAKCmLg7fUG0YSywkQexoPL+L3JpQtACgs20s DuKsOulPJx4bGfArpN101zE= =yuFl -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: secure installation
[EMAIL PROTECTED] un jour écrivit: All I'm saying is, would it be possible to have a single simple option that users could *elect* to take, that wasn't the default, that wasn't bending anyones life out of shape, marked "Novice User" or something :-) A question during the Debian installation about installing a firewall that default to no? Yes, that would be possible. But I am not sure I would want to put that for a novice user. What I see comming, is many more newbies users complaining on the mailling lists that application xyz doesn't work properly. Example, they downloaded bittorent (instead of just installing one of the existing Debian package), and then complain that It doesn't work. We all agree that having a firewall is a good line of defense, but the most important is not having unneeded services listening to the net, and that the code of the software doing network interaction be secure. A computer that is secure, should be secure regardless of the presence of a firewall. Otherwise, It will simply give you a false sense of security, which is worst. I never used lokkit, but I guess It would need to be reconfigured everytime someone install a software that use the net, because a real novice user will not think about reconfiguring his firewall when needed, and know even less which ports needs to be opened. So installing by default a firewall for new user will probably creates more problems than It will solve, and not makes the computer significantly more secure (many trojan will use port 80 or 21 anyway). But adding the option to install a firewall in the expert mode makes sense to me. Simon Valiquette -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ftpd - security thread ?
François TOURDE un jour écrivit: > Le 13639ième jour après Epoch, > Lubos Rendek écrivait: >> Can anyone explain why is this happening? Why is my box connecting to >> that IP address without me actually knowing about that? > > Perhaps it's because ftp.wa.au.debian.org (aka poledra.it.net.au) is > listed in http://www.fr.debian.org/CD/http-ftp/ as a Debian mirror ? > :) I first tough It could be him simply downloading this package from an autralian http mirror. I found out to effectively be the IP for ftp.wa.au.debian.org, but I received your email only when I was about to answer. How to reproduce It? apt-get -Vu remove --purge ftpd Then your next installation will again download ftpd from this mirror. Unless me missed something, problem solved. Simon Valiquette -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GPG errors from apt update
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Stephen Gran un jour écriva: > > It sounds like the mirror is toast. Please mail the mirror admins. > I don't have an email address off hand, sorry, but it should be > either on the mirrors page or the organization page of debian.org. Behind ftp.us.debian.org, there is actually 4 mirrors, so there is not any specific email address about it except maybe the Debian mirror mailing list. Could it be a problem with only one of those mirrors? Here the 4 servers deserving ftp.us.debian.org if you wish to check them individually: ike.egr.msu.edu archive.progeny.com debian-mirror.mirror.umn.edu mirrors1.kernel.org Could it be something about bad synchronization between those servers? I don't think it should happens under normal circumstances, especially with the 2-stages mirroring scheme, but it might be worth to verify. Simon Valiquette http://gulus.USherbrooke.ca -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Linux PPC) iD8DBQFE96xfJPE+P+aMAJIRA448AJ423Wn32g6MgB6fM+yDCytZ2wiXtgCeNMkp RkaffrOc1zYvs1gWLCQKuJQ= =xJSd -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
