Apache 1.3.27 is out...
Apache 1.3.27 is out to fix 3 security vulnerabilities in 1.3.26 and below. Are fixed pacakges on their way to security.debian.org? Did ASF notify any vendors in advance of their announcement today? http://www.apache.org/dist/httpd/Announcement.html -- Paul Baker "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin, 1759 GPG Key: http://homepage.mac.com/pauljbaker/public.asc
Apache 1.3.27 is out...
Apache 1.3.27 is out to fix 3 security vulnerabilities in 1.3.26 and below. Are fixed pacakges on their way to security.debian.org? Did ASF notify any vendors in advance of their announcement today? http://www.apache.org/dist/httpd/Announcement.html -- Paul Baker "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin, 1759 GPG Key: http://homepage.mac.com/pauljbaker/public.asc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [SECURITY] [DSA 149-1] New glibc packages fix security related problems
On Tuesday, August 13, 2002, at 03:21 AM, Martin Schulze wrote: - -- Debian Security Advisory DSA 149-1 [EMAIL PROTECTED] http://www.debian.org/security/ Martin Schulze August 13th, 2002 - -- Package: glibc Vulnerability : integer overflow Problem-Type : remote Debian-specific: no CVE Id : CAN-2002-0391 CERT advisory : VU#192995 Anyone aware of any particular daemon's that need to be restarted just to be safe? I'd rather not have to type in the SSL passphrase for apache+mod_ssl if I don't have to. -- Paul Baker "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin, 1759 GPG Key: http://homepage.mac.com/pauljbaker/public.asc
potato libssl09 package vulnerable?
So I see that the openssl, libssl-dev, libssl0.9.6 packages in potato have been fixed for DSA-136-1. I'm wondering if the libssl09 packages are also vulnerable to this exploit? If it is, is a fixed package going to be out soon, or should I be expending the effort to back port woody's openssl094 package myself? -- Paul Baker "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin, 1759 GPG Key: http://homepage.mac.com/pauljbaker/public.asc
Re: [SECURITY] [DSA-136-1] Multiple OpenSSL problems
On Thursday, August 1, 2002, at 06:35 PM, [EMAIL PROTECTED] wrote: You might find the checkinstall package to be of some use here. It's worked quite nicely for most things I've tried it for. That would be more of the quick short cut way of doing it which always seems to byte you in the ass later (perhaps when sarge is released). Also it expects you to be installing software that has 'make install' etc. Which our software doesn't necessarily have either. So as part of turning everything into debian packages, they will also get nice shiny Makefiles. -- Paul Baker "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin, 1759 GPG Key: http://homepage.mac.com/pauljbaker/public.asc
Re: [SECURITY] [DSA-136-1] Multiple OpenSSL problems
On Thursday, August 1, 2002, at 01:33 PM, Ted Deppner wrote: On Thu, Aug 01, 2002 at 12:19:52PM -0500, Paul Baker wrote: Is there an ETA yet on potato packages, or should I continue to try and backport the woody packages to my potato machines myself? Just as an encouragement, the upgrade process from potato to woody is pretty painless. I've already done all my public facing machines without any "real" service downtime, need to reboot, etc. Yeah it *should* be painless. Unfortuneately, we are using our own compiled apache, mod*, mysql, and a few other things in /usr/local. As part of the upgrade to woody though I want to start using only Debian versions of software. So there is a bit of extra testing/configuring involved to make that work. We also were using our own version of perl 5.6.1 in /usr/local. Want to start using Debian's 5.6.1. This also means that any locally installed CPAN modules will be in the wrong place to work with that perl, so there is further work involved in making sure that all the perl modules we are using get installed from woody, and if not, that we get them from sid, or make them ourselves. Further than that I also want to make all of our own companies software into Debian packages as part of the rollout of Woody. This is the long and painful part. It's more or less an all or nothing task, so there is a LOT of testing involved in making sure this transition is smooth so we don't have any downtime. And of course I understand that all of the above is not Debian's fault. But it is the reason I hope Debian supports Potato longer than they did slink because I have a ton of work ahead of me. :-) -- Paul Baker "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin, 1759 GPG Key: http://homepage.mac.com/pauljbaker/public.asc
Re: [SECURITY] [DSA-136-1] Multiple OpenSSL problems
On Tuesday, July 30, 2002, at 07:47 AM, Wichert Akkerman wrote: -BEGIN PGP SIGNED MESSAGE- - Debian Security Advisory DSA-136-1 [EMAIL PROTECTED] http://www.debian.org/security/ Wichert Akkerman July 30, 2002 - Package: openssl Problem type : multiple remote exploits Debian-specific: no CVE: CAN-2002-0655 CAN-2002-0656 CAN-2002-0657 CAN-2002-0659 [..snip..] These vulnerabilities are also present in Debian 2.2 (potato), but no fix is available at this moment. We recommend you upgrade your OpenSSL as soon as possible. Note that you should restart any daemons running SSL. (E.g., ssh or ssl-enabled apache.) Is there an ETA yet on potato packages, or should I continue to try and backport the woody packages to my potato machines myself? -- Paul Baker "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin, 1759 GPG Key: http://homepage.mac.com/pauljbaker/public.asc
http://www.debian.org/security/2002/dsa-136
The web page for the DSA-136 advisory at http://www.debian.org/security/2002/dsa-136 says "Debian GNU/Linux 2.2 (potato)" above the list of fixed packages for Woody. Somebody might want to fix that. -- Paul Baker "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin, 1759 GPG Key: http://homepage.mac.com/pauljbaker/public.asc
Re: openssh packages not vulnerable
On Wednesday, June 26, 2002, at 03:50 PM, Richard wrote: Even worse, on 2.0.x kernels "PrivilegeSeparation" doesn't work, rendinging sshd useless for interactive sessions or make it vurneble is you disable it. All debian versions of ssh packages are not vulnerable, AFAIK. I'm hoping the security team will make an official announcement. -- Paul Baker "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin, 1759 GPG Key: http://homepage.mac.com/pauljbaker/public.asc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
openssh packages not vulnerable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 So as it turns out, AFAIK, none of the versions of OpenSSH in Debian were actually vulnerable to the exploit found by ISS and reported in DSA-134 Potato wasn't vulnerable because it is SSH1 only, and the problem lies in the ChallengeResponseAuthentication feature that only exists in the SSH2 protocol. Also in order to be vulnerable, either S/KEY or BSD_AUTH authentication mechanism needed to be enabled at compile time. The woody/sid packages do not enable either of these features. So what it all boils down to is that at no time was Debian vulnerable to this problem. I'm curious what recourse Debian is planning to take now? Perhaps removing the buggy OpenSSH 3.3 packages off of security.debian.org so people don't upgrade to it since it's not at all necessary and it will only cause problems like screwing up compression and pam. - -- Paul Baker "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin, 1759 GPG Key: http://homepage.mac.com/pauljbaker/public.asc -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (Darwin) Comment: For info see http://www.gnupg.org iD8DBQE9GheLoxmRVfL3nlsRAmM4AJ9mBv0mgZhEqW/Duzoj5SUQw4UewACeICe+ I6wH9uksQP9RJMpZk5YNqQc= =jknM -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: the openssh exploit
On Tuesday, June 25, 2002, at 11:14 AM, Phillip Hofmeister wrote: On Tue, Jun 25, 2002 at 02:40:19AM -0400, Anthony DeRobertis wrote: Note that to do (1), you must insure that the real machine does not send a RST in response to the SYN|ACK. Ways to do this are numerous; DoS attacks come to mind. Or just use an unused IP He was talking about spoofing ips that I am allowing access for in my firewall. All the ips I'm allowing are for existing machines, so an unused IP would be one that is not allowed through the firewall already. -- Paul Baker "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin, 1759 GPG Key: http://homepage.mac.com/pauljbaker/public.asc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: the openssh exploit
On Monday, June 24, 2002, at 11:20 PM, David B Harris wrote: We have no way of being sure, since the nature of the exploit and the specifics aren't being told. However, supposedly, you need to be able to talk to the sshd in order to exploit it. So if nothing (or nothing malicious) can open a connection, you're fine. Does the tcp_wrapper use in openssh work that way? It's not like ssh is running from inetd first being passed through tcpd. I'm just using the builtin tcpwrapper support of openssh, so I would guess that that means technically, sshd is handling the request long enough to at least see what ip it is coming from. May be time to modify my firewall rules. argh! Of course maybe that won't even help. Of course we don't know because openbsd is keeping a tight lip, but potentially maybe someone could craft a malicious packet that appears to come from one of the trusted ips?? -- Paul Baker "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin, 1759 GPG Key: http://homepage.mac.com/pauljbaker/public.asc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
the openssh exploit
Does anyone know if the openssh exploit that 3.3 is supposed to not fix, but do damage control for, is it still exploitable if you have set your /etc/hosts.deny to deny all hosts, and then /etc/hosts.allow to only allow from trusted ips. In other words, if a malicious ssh request comes from an ip that is already denied via tcp_wrapper support in ssh, will it still be able to exploit OpenSSH < 3.3? I'm not on the list, so cc me please. -- Paul Baker "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin, 1759 GPG Key: http://homepage.mac.com/pauljbaker/public.asc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
