DSA 992-1 affecting other packages?
Hi, I noticed today on Debian Weekly News that FFMpeg has had a security-related bug. Are you aware that ffmpeg in Debian ships static libraries? If I understand correctly, this means other packages building against FFMpeg (Xine, GStreamer and VLC comes to my mind) actually contain a copy of the libavcodec library rather than linking to it dynamically - and must then also all of them be rebuilt, pulling in the security-fixed library. The reason for the static linking, I believe, is that FFMpeg upstream has recommended to use static linking due to the ABI (or is it API) not yet stable. I suspect, however, that this could be dealt with differently for Debian (and I suspect this to be against policy, but is incapable technically to take up an argument about that). - Jonas -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ - Enden er nær: http://www.shibumi.org/eoti.htm pgp5ZkNw4vq2E.pgp Description: PGP signature
Re: DSA 992-1 affecting other packages?
Jonas Smedegaard wrote: Are you aware that ffmpeg in Debian ships static libraries? If I understand correctly, this means other packages building against FFMpeg (Xine, GStreamer and VLC comes to my mind) actually contain a copy of the libavcodec library rather than linking to it dynamically - and must then also all of them be rebuilt, pulling in the security-fixed library. Yes, updates for xine-lib, gst-ffmpeg and vlc are in preparation. motion and kino link statically against libavcodec as well, but don't use the vulnerable code. The reason for the static linking, I believe, is that FFMpeg upstream has recommended to use static linking due to the ABI (or is it API) not yet stable. I suspect, however, that this could be dealt with differently for Debian (and I suspect this to be against policy, but is incapable technically to take up an argument about that). Indeed, it would be very desirable if that could be fixed for Etch, it's not unlikely that further libavcodec issues will be found during Etch lifetime. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [gna-private] [SECURITY] [DSA 987-1] New tar packages fix arbitrary code execution
Moritz Muehlenhoff wrote: This question comes from time to time. If someone wants to write a FAQ entry for the Debian Security FAQ, please send it to [EMAIL PROTECTED] It's now documented in the Debian Security FAQ. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
unsubscribe
-Mensaje original- De: Martin Schulze [mailto:[EMAIL PROTECTED] Enviado el: miércoles, 15 de marzo de 2006 9:43 Para: Debian Security Announcements Asunto: [SECURITY] [DSA 1002-1] New webcalendar packages fix several vulnerabilities -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- Debian Security Advisory DSA 1002-1[EMAIL PROTECTED] http://www.debian.org/security/ Martin Schulze March 15th, 2006http://www.debian.org/security/faq - -- Package: webcalendar Vulnerability : several Problem type : remote Debian-specific: no CVE IDs: CVE-2005-3949 CVE-2005-3961 CVE-2005-3982 CERT advisory : BugTraq IDs: 15606 15608 15662 15673 Debian Bugs: 341208 342090 Several security related problems have been discovered in webcalendar, a PHP based multi-user calendar. The Common Vulnerabilities and Exposures project identifies the following vulnerabilities: CVE-2005-3949 Multiple SQL injection vulnerabilities allow remote attackers to execute arbitrary SQL commands. CVE-2005-3961 Missing input sanitising allowas an attacker to overwrite local files. CVE-2005-3982 A CRLF injection vulnerability allows remote attackers to modify HTTP headers and conduct HTTP response splitting attacks. The old stable distribution (woody) does not contain webcalendar packages. For the stable distribution (sarge) these problems have been fixed in version 0.9.45-4sarge3. For the unstable distribution (sid) these problems have been fixed in version 1.0.2-1. We recommend that you upgrade your webcalendar package. Upgrade Instructions - wget url will fetch the file for you dpkg -i file.deb will install the referenced file. If you are using the apt-get package manager, use the line for sources.list as given below: apt-get update will update the internal database apt-get upgrade will install corrected packages You may use an automated update by adding the resources from the footer to the proper configuration. Debian GNU/Linux 3.1 alias sarge - Source archives: http://security.debian.org/pool/updates/main/w/webcalendar/webcalendar_0 .9.45-4sarge3.dsc Size/MD5 checksum: 610 a0cd6c66192d6fcb08ad235bab03682f http://security.debian.org/pool/updates/main/w/webcalendar/webcalendar_0 .9.45-4sarge3.diff.gz Size/MD5 checksum:11838 01cadcadb69aea8688183bf7093b90e8 http://security.debian.org/pool/updates/main/w/webcalendar/webcalendar_0 .9.45.orig.tar.gz Size/MD5 checksum: 612360 a6a66dc54cd293429b604fe6da7633a6 Architecture independent components: http://security.debian.org/pool/updates/main/w/webcalendar/webcalendar_0 .9.45-4sarge3_all.deb Size/MD5 checksum: 629166 eebb63997aa535fce008490679d89b3a These files will probably be moved into the stable distribution on its next update. - -- --- For apt-get: deb http://security.debian.org/ stable/updates main For dpkg-ftp: ftp://security.debian.org/debian-security dists/stable/updates/main Mailing list: debian-security-announce@lists.debian.org Package info: `apt-cache show pkg' and http://packages.debian.org/pkg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEF9OJW5ql+IAeqTIRAke9AJ0csITsMHmHs4ncMlRCiNfObGeZpQCeIaHm 6+AFNmAybHujJNRTpNmg90s= =02az -END PGP SIGNATURE- -- 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: Idea to secure ssh
Michel Messerschmidt [EMAIL PROTECTED] writes: Neal Murphy said: The point is to obscure the ssh server from everyone, including those who are authorized to access it remotely. You're right, this is just the old idea of security by obscurity. And quite pointless. Better install a fake sshd on every system that would randomly allow in users and then drop them into nirvana without doing much actual cpu intentsive auth. Give them so many false positives that their scanning becomes utterly pointless. :))) The point is to reduce brute-forace attacks to the point of nearly total ineffectiveness. The point is to require a small amount of pre-authentication before the server acknowledges the client's attempt to connect. How small can any _reliable_ authentication protocol be? Either it's at risk by brute-force or by denial-of-service. Except now, instead of just getting slow, the network and server just drop UDP packets and overhear knocking on the door by valid users due to the hailstorm of brute force knocks. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Idea to secure ssh
Michael Stone [EMAIL PROTECTED] writes: On Mon, Mar 13, 2006 at 03:03:24PM -0500, Neal Murphy wrote: Yes, allowing UDP packets in is, in a sense, an open port, but it's a one-way port. UDP packets have a fixed maximum size and the information carried in the packet is trivial in nature; UDP packets are generally benign. It's a given that anyone who knows the server's public key can generate an encrypted packet, but only an authorized user can correctly generate the encrypted parts inside the encrypted packet. No, anyone can generate encrypted parts. IMHO, there's not much chance that the decryption routines in your magic udp parser are going to be less vulnerable than those in openssh itself. Having two layers of Having two layers of encryption in this context is fairly pointless. Those two layers are totaly standard. You have to use two keypairs in parallel to ensure that only one person can read the text and only one person can have send it. Why not use three layers, or four? What analysis demonstrates a demonstrable return for that second layer, weighed against the cost of this kooky mechanism? If you really need multiple encryption layers, do it right and use an existing standard like ipsec rather than inventing a convoluted secret method. The analysis is simple: Encrypting with the server public key ensures that only the server private key can decrypt the data. Encrypting with the client private key ensures that only the client can have send the package. Decryptng with the clients public key ensures that. The replies by the server are encrypted in reverse for the same reasons. That way there can be no fake reader or writer in the middle. Mike Stone MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Idea to secure ssh
On Wed, Mar 15, 2006 at 02:35:53PM +0100, Goswin von Brederlow wrote: Michael Stone [EMAIL PROTECTED] writes: No, anyone can generate encrypted parts. IMHO, there's not much chance that the decryption routines in your magic udp parser are going to be less vulnerable than those in openssh itself. Having two layers of Having two layers of encryption in this context is fairly pointless. Those two layers are totaly standard. You have to use two keypairs in parallel to ensure that only one person can read the text and only one person can have send it. Either that paragraph doesn't parse or it doesn't address what I said. This gets back to what are you trying to defend against. If you're trying to defend against brute force attacks, then the ssh public key auth should be sufficient. If it's not (if your adversary can somehow crack or brute force arbitrary RSA keys) than adding a *second* key isn't going to help. If you're trying to defend against attacks on the crypto routines themselves (e.g., a buffer overflow against the RSA code in openssh) then I don't see why this other parser is going to be more secure. What problem is this frankenstein trying to solve? Why not use three layers, or four? What analysis demonstrates a demonstrable return for that second layer, weighed against the cost of this kooky mechanism? If you really need multiple encryption layers, do it right and use an existing standard like ipsec rather than inventing a convoluted secret method. The analysis is simple: Encrypting with the server public key ensures that only the server private key can decrypt the data. Encrypting with the client private key ensures that only the client can have send the package. Decryptng with the clients public key ensures that. Dude, openssh *already does that*. Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Idea to secure ssh
Michael Stone [EMAIL PROTECTED] writes: On Wed, Mar 15, 2006 at 02:35:53PM +0100, Goswin von Brederlow wrote: Michael Stone [EMAIL PROTECTED] writes: No, anyone can generate encrypted parts. IMHO, there's not much chance that the decryption routines in your magic udp parser are going to be less vulnerable than those in openssh itself. Having two layers of Having two layers of encryption in this context is fairly pointless. Those two layers are totaly standard. You have to use two keypairs in parallel to ensure that only one person can read the text and only one person can have send it. Either that paragraph doesn't parse or it doesn't address what I said. This gets back to what are you trying to defend against. If you're trying to defend against brute force attacks, then the ssh public key auth should be sufficient. If it's not (if your adversary can somehow crack or brute force arbitrary RSA keys) than adding a *second* key isn't going to help. If you're trying to defend against attacks on the crypto routines themselves (e.g., a buffer overflow against the RSA code in openssh) then I don't see why this other parser is going to be more secure. What problem is this frankenstein trying to solve? He trying to solve that a tcp connect to port 22 establishes a connection and thereby reveals that the server is running an sshd and attcking it makes sense. His idea is to add a 100% non responsive knocking (using udp) before the actual ssh handshake so unauthorized clients can't even determine that sshd is running. Not that I find that usefull but thats the idea. Why not use three layers, or four? What analysis demonstrates a demonstrable return for that second layer, weighed against the cost of this kooky mechanism? If you really need multiple encryption layers, do it right and use an existing standard like ipsec rather than inventing a convoluted secret method. The analysis is simple: Encrypting with the server public key ensures that only the server private key can decrypt the data. Encrypting with the client private key ensures that only the client can have send the package. Decryptng with the clients public key ensures that. Dude, openssh *already does that*. Obviously. Anything less and you can jjst use telnet. Mike Stone MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Idea to secure ssh [was: howto block ssh brute-force]
Neal Murphy wrote: The point is to reduce brute-forace attacks to the point of nearly total ineffectiveness. I use OpenSSH public/private key authentication to achieve this. Based on needs one could also use two factor authentication (e.g. one time password tokens) or even a combination of methods. These are standard tools you can use to defeat the weak password solution. It is always better to eliminate problems at their root, which in that case are accounts with weak passwords. The point is to obscure the ssh server from everyone, including those who are authorized to access it remotely. I only see you add an obscuring (and encrypting) shield around your service. I'd say that implementing such a complex solution will bring more problems than it will solve (another layer to debug ;) ). I would rather go the KISS way: key auth, non standard ports, fail2ban. As an admin I would rather stick with a hardened SSH gateway, using strong authentication and end user education, than adding an UDP layer. Another example: We have to run a CVS server that is reachable from the outside, so that some external devs can upload their changes. I got two SSH instances running on that box, one on port 22 that is only reachable from our internal network and one on a non standard port reachable worldwide. The worldwide SSH only accepts logins for a certain group of CVS users, key authentication is enforced and a restricted shell is used that only allows CVS. Up to now (running for approx one year) no automated SSH attack was logged on the non standard port. Full port scans with service identification are seldom and if so, indicate a more detemined attacker. Regards, Tom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Serious bug in security update for Crypt::CBC
Hi all! Sorry to be jumping in without preserving the In-Reply-To. Allard Hoeve wrote: I'm afraid this new package introduces some serious errors in software that depends on this package. I have tested the new package on three different Sarge machines with the following results. Please reproduce using attached perl script. This bug jumped up and bit us too during testing, and it has been reported as bug #356810: http://bugs.debian.org/356810 so, it is now clear that it poses a serious problem for users, as it breaks the default behaviour. However, Please remove the update from the security archive. ...it is not that simple. If you read the original advisory: http://www.securityfocus.com/archive/1/archive/1/425966/100/0/threaded you'll see that we have (indirectly) been relying on weak and deprecated behaviour. While this is not the sort of breakage you expect from stable, it underlines that security is not just about blindly upgrading packages. So, it is probably better to get a heads-up from something that breaks down than getting the heads up from someone who breaks in... :-) The problem in this case is that we don't know if it is serious: The difficulty of breaking data encrypted using this flawed algorithm is unknown, but it should be assumed that all information encrypted in this way has been, or could someday be, compromised. Given that the upgrade certainly breaks stable, a DSA could have suggested the workaround as the correct path for sysadmins: If using Crypt::CBC versions 2.16 and lower, pass the -salt=1 option to Crypt::CBC-new(). I.e., say you should do this now to upgrade your systems. Many users are likely to be bit by this upgrade, so, indeed, it may be a reasonable path to remove the security upgrade and instead suggest the workaround. Best, Kjetil -- Kjetil Kjernsmo Information Systems Developer Opera Software ASA pgpQXF0ABTsYf.pgp Description: PGP signature
Re: Idea to secure ssh
On Wed, Mar 15, 2006 at 05:06:34PM +0100, Goswin von Brederlow wrote: His idea is to add a 100% non responsive knocking (using udp) before the actual ssh handshake so unauthorized clients can't even determine that sshd is running. Not that I find that usefull but thats the idea. Traditional port knocking gets you that without a goofy encryption layer. Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
unsubscribe
Gary Foster CTO, Pace Systems Group, Inc. office: 800-624-5999 x9104 mobile: 904-226-4901 fax:925-871-4511 -Original Message- From: Martin Schulze [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 15, 2006 3:43 AM To: Debian Security Announcements Subject: [SECURITY] [DSA 1002-1] New webcalendar packages fix several vulnerabilities -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- Debian Security Advisory DSA 1002-1[EMAIL PROTECTED] http://www.debian.org/security/ Martin Schulze March 15th, 2006http://www.debian.org/security/faq - -- Package: webcalendar Vulnerability : several Problem type : remote Debian-specific: no CVE IDs: CVE-2005-3949 CVE-2005-3961 CVE-2005-3982 CERT advisory : BugTraq IDs: 15606 15608 15662 15673 Debian Bugs: 341208 342090 Several security related problems have been discovered in webcalendar, a PHP based multi-user calendar. The Common Vulnerabilities and Exposures project identifies the following vulnerabilities: CVE-2005-3949 Multiple SQL injection vulnerabilities allow remote attackers to execute arbitrary SQL commands. CVE-2005-3961 Missing input sanitising allowas an attacker to overwrite local files. CVE-2005-3982 A CRLF injection vulnerability allows remote attackers to modify HTTP headers and conduct HTTP response splitting attacks. The old stable distribution (woody) does not contain webcalendar packages. For the stable distribution (sarge) these problems have been fixed in version 0.9.45-4sarge3. For the unstable distribution (sid) these problems have been fixed in version 1.0.2-1. We recommend that you upgrade your webcalendar package. Upgrade Instructions - wget url will fetch the file for you dpkg -i file.deb will install the referenced file. If you are using the apt-get package manager, use the line for sources.list as given below: apt-get update will update the internal database apt-get upgrade will install corrected packages You may use an automated update by adding the resources from the footer to the proper configuration. Debian GNU/Linux 3.1 alias sarge - Source archives: http://security.debian.org/pool/updates/main/w/webcalendar/webcalendar_0.9.4 5-4sarge3.dsc Size/MD5 checksum: 610 a0cd6c66192d6fcb08ad235bab03682f http://security.debian.org/pool/updates/main/w/webcalendar/webcalendar_0.9.4 5-4sarge3.diff.gz Size/MD5 checksum:11838 01cadcadb69aea8688183bf7093b90e8 http://security.debian.org/pool/updates/main/w/webcalendar/webcalendar_0.9.4 5.orig.tar.gz Size/MD5 checksum: 612360 a6a66dc54cd293429b604fe6da7633a6 Architecture independent components: http://security.debian.org/pool/updates/main/w/webcalendar/webcalendar_0.9.4 5-4sarge3_all.deb Size/MD5 checksum: 629166 eebb63997aa535fce008490679d89b3a These files will probably be moved into the stable distribution on its next update. - - For apt-get: deb http://security.debian.org/ stable/updates main For dpkg-ftp: ftp://security.debian.org/debian-security dists/stable/updates/main Mailing list: debian-security-announce@lists.debian.org Package info: `apt-cache show pkg' and http://packages.debian.org/pkg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEF9OJW5ql+IAeqTIRAke9AJ0csITsMHmHs4ncMlRCiNfObGeZpQCeIaHm 6+AFNmAybHujJNRTpNmg90s= =02az -END PGP SIGNATURE- -- 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: Idea to secure ssh
On Wednesday 15 March 2006 11:06, Goswin von Brederlow wrote: He trying to solve that a tcp connect to port 22 establishes a connection and thereby reveals that the server is running an sshd and attcking it makes sense. His idea is to add a 100% non responsive knocking (using udp) before the actual ssh handshake so unauthorized clients can't even determine that sshd is running. Not that I find that usefull but thats the idea. Thank you! You stated it in simple terms that escaped me. If the only brute-force attempts come from a single address, then simpler methods of detecting and blocking such attempts may be adequate. If one is quite satisfied leaving the barn door wide open while having an obviously secure lock on the door of the stall holding his prized thoroughbred, then no extra security is needed. For me, putting an obvious, very visible lock on the stall door is not sufficient; I'd like to obscure all of the stall doors so that the good locks aren't obvious, and secure the barn itself. I wouldn't put up flags and banners crying out to all passers-by that I may have something valuable inside. I want thieves to think, There's nothing here worth stealing; I'll keep going to the next place while they are still on road passing by. Considering that many miscreants have 'armies' of cracked Windows computers they control remotely, many concerted attacks won't necessarily come from one IP or one network. Concerted spam attacks don't come from a single source. DDOS attacks don't come from a single source. If shooing the intruder away after he's been picking away at your system for a while is good enough for you, then good. You don't need anything else. But I think there are plenty of others who, like me, don't want to give miscreants any reason to stop and pick away at all. We want them to stay on the road and pass right by. And we want to be ready for them if they do happen to stop. Neal -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
