[SECURITY] [DSA-374-1] New libpam-smb packages fix buffer overflow
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- Debian Security Advisory DSA 374-1 [EMAIL PROTECTED] http://www.debian.org/security/ Matt Zimmerman August 26th, 2003 http://www.debian.org/security/faq - -- Package: libpam-smb Vulnerability : buffer overflow Problem-Type : remote Debian-specific: no CVE Ids: CAN-2003-0686 libpam-smb is a PAM authentication module which makes it possible to authenticate users against a password database managed by Samba or a Microsoft Windows server. If a long password is supplied, this can cause a buffer overflow which could be exploited to execute arbitrary code with the privileges of the process which invokes PAM services. For the stable distribution (woody) this problem has been fixed in version 1.1.6-1.1woody1. For the unstable distribution (sid) does not contain a libpam-smb package. We recommend that you update your libpam-smb 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.0 alias woody - Source archives: http://security.debian.org/pool/updates/main/libp/libpam-smb/libpam-smb_1.1.6-1.1woody1.dsc Size/MD5 checksum: 593 c6c56d7b6260ae8049815e3a43fb58d9 http://security.debian.org/pool/updates/main/libp/libpam-smb/libpam-smb_1.1.6-1.1woody1.diff.gz Size/MD5 checksum: 6807 572c7940030bbab2c373492ab2a4556f http://security.debian.org/pool/updates/main/libp/libpam-smb/libpam-smb_1.1.6.orig.tar.gz Size/MD5 checksum:66705 7d18363b7ab932f852f670b4aeed1283 Alpha architecture: http://security.debian.org/pool/updates/main/libp/libpam-smb/libpam-smb_1.1.6-1.1woody1_alpha.deb Size/MD5 checksum:32704 5f5a890823818b8f1b245177c308078f ARM architecture: http://security.debian.org/pool/updates/main/libp/libpam-smb/libpam-smb_1.1.6-1.1woody1_arm.deb Size/MD5 checksum:24910 5313c2a58969cacf1e9b1f2344bb30fa Intel IA-32 architecture: http://security.debian.org/pool/updates/main/libp/libpam-smb/libpam-smb_1.1.6-1.1woody1_i386.deb Size/MD5 checksum:24894 a8f615d27f2d18a67dfec638cfb9f403 Intel IA-64 architecture: http://security.debian.org/pool/updates/main/libp/libpam-smb/libpam-smb_1.1.6-1.1woody1_ia64.deb Size/MD5 checksum:38686 ca963283abd88c8af5c9971d3d1c2938 HP Precision architecture: http://security.debian.org/pool/updates/main/libp/libpam-smb/libpam-smb_1.1.6-1.1woody1_hppa.deb Size/MD5 checksum:28082 8b5fd0d0a2fc57c731f152b02704d7fe Motorola 680x0 architecture: http://security.debian.org/pool/updates/main/libp/libpam-smb/libpam-smb_1.1.6-1.1woody1_m68k.deb Size/MD5 checksum:24368 df246feb56f538e19e0ecab0aede35a4 Big endian MIPS architecture: http://security.debian.org/pool/updates/main/libp/libpam-smb/libpam-smb_1.1.6-1.1woody1_mips.deb Size/MD5 checksum:26752 6b4c2d1c038147db28a79a844535b503 Little endian MIPS architecture: http://security.debian.org/pool/updates/main/libp/libpam-smb/libpam-smb_1.1.6-1.1woody1_mipsel.deb Size/MD5 checksum:26572 5698fae87f00d6d2eecc26b0a0fe2e19 PowerPC architecture: http://security.debian.org/pool/updates/main/libp/libpam-smb/libpam-smb_1.1.6-1.1woody1_powerpc.deb Size/MD5 checksum:26974 4365a22a1d2e85d39c423cce11f5f06a IBM S/390 architecture: http://security.debian.org/pool/updates/main/libp/libpam-smb/libpam-smb_1.1.6-1.1woody1_s390.deb Size/MD5 checksum:26594 8b60eee47dae392e67ea1ff763916cdf Sun Sparc architecture: http://security.debian.org/pool/updates/main/libp/libpam-smb/libpam-smb_1.1.6-1.1woody1_sparc.deb Size/MD5 checksum:28794 52eb7d68bbd6181a084aa201e3f96f0d These files will probably be moved into the stable distribution on its next revision. - - 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: [EMAIL PROTECTED] Package info: `apt-cache show pkg' and http://packages.debian.org/pkg -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/S4HnArxCt0PiXR4RAvfZAJ40nRVpT+e5+H/UnzhBse2iLyH1wACfWvC4 k6oDWclcjW3iR9uWOtIdBVw= =v9EV -END PGP SIGNATURE- -- To UNSUBSCRIBE,
Re: Looking for a simple SSL-CA package
- Original Message - From: Tarjei Huse [EMAIL PROTECTED] To: Noah L. Meyerhans [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Sunday, August 24, 2003 1:51 PM Subject: Re: Looking for a simple SSL-CA package I think I'll end up with pyca (www.pyca.org) as it seems to have most of these features in place. The other possibilities are openca which is IMHO to complicated for my needs and tinyca (that many on this list suggested) that doesn't (please correct me if I'm wrong) give me the finished scripts for importing certs in outlook, IE, Mozilla and other programs. If there are other alternatives out there, please let me know. Again, I thank you for your contributions. Tarjei Apologies if I am repeating someone else's points, I haven't followed the thread in depth. It sounds kind of kooky, but we have operated a CA for about 2 years, having about 400 users, using just openssl and a few hand turned scripts and a dynamic webpage. User info is maintained in MySQL, though we let openssl maintain the CA history in text files. The CA doesn't do any of the Outlook, IE, Mozilla etc importing - those programs do that, you just have to know what sort of certs to generate, and how to trigger the import processing on the client. We use a webpage and several variants of the XEnroll object for IE v 5.01-6.0 where IE generates the keypairs, and creates a CSR which gets posted to the webserver. We then sign the request and create a x-pkcs7-certificates [.p7b file] which is returned to the webserver for the user to download (they hit the Refresh button on the request page). There are some busted Office XP upgrade paths, for which we have to generate the keypair on our server in a PKCS12 format [.pfx file] - which we then make available to the user via the webpage. NS/Mozilla is easy - as per IE, we get the client to generate a CSR which gets posted to our webserver. We sign the certificate, x-x509-user-cert [.cct file] and copy it back to the webserver for the user to install. The only bugbear is that Mozilla succeeds silently, so you can't easily throw up a warning if the import failed for some reason [failure is rare]. Outlook will recognise your CA as an authority for secure pop and imap connections, if you import your self-signed CA cert in IE - just get your users to download your CA cert x-x509-ca-cert [.crt file] from a website, and click on Install Cert. Regards Jeff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
unsubscribe
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
towards a taxonomy of Information Assurance (IA)
Fellow Information Security Professionals, Bottom line: I'd like your help in shaping a usable taxonomy of Information Assurance.* This taxonomy is part of my graduate studies, and will not be used for any commercial purposes. It will remain an open source open project. I am presently working on creating a taxonomy of information assurance, based on the three aspects of: (1) Information characteristics (2) Information states (3) Security countermeasures These three aspects of Information Assurance (IA) were highlighted by John McCumber [1] as well as a team of West Point researchers [2] as a component of works that define an integrated approach to security. I have also considered the works of Matt Bishop [3] in how to create a useful taxonomy. Within the next 6 months, I would like to create a taxonomy that graphically depicts the relationships of these three aspects. I will use an open source model whereby all of my findings results will be posted for public review and revision. My intent is that this taxonomy could be used by the academic community, industry, and government in improving the precision of communication used in discussing information assurance/security topics. I have searched the Internet widely for a taxonomy of Information Assurance, but I have not found anything that is sufficiently detailed for application with real world problems. I've posted my initial results to the following URL: http://www.sharp-ideas.net/ia/information_assurance.htm for comments and peer review. Cheers, Abe Usher [EMAIL PROTECTED] * Information assurance is defined as information operations that protect and defend information and information systems by ensuring their availability, integrity, authentication, confidentiality, and non-repudiation. This includes providing for restoration of information systems by incorporating protection, detection, and reaction capabilities. [1] McCumber, John. Information Systems Security: A Comprehensive Model. Proceedings 14th National Computer Security Conference. National Institute of Standards and Technology. Baltimore, MD. October 1991. [2] Maconachy, Victor, Corey Schou, Daniel Ragsdale, and Don Welch. A Model for Information Assurance: An Integrated Approach. Proceedings of the 2001 IEEE Workshop on Information Assurance and Security. U.S. Military Academy. West Point, NY. June 2001. [3] Bishop, Matt. A Critical Analysis of Vulnerability Taxonomies. Department of Computer Science, University of California. Davis, CA. September 1996. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[no subject]
Mike Lewis Business Systems Analyst Mississippi Band of Choctaw Indians dba Chahta Enterprise Enterprise Headquarters for our Wiring Harness Manufacturing Division Commercial Laundry Division Geospatial and Information Technology Division 390 Industrial Road Choctaw, MS 39350 601-656-7350 x 102 601-656-8785 - Fax -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
The possibility of malicious code in the Debian unstable libtool-1.5package
As I am sure most of you on this list are aware, GNU recently discovered that their ftp file server was owned for many months by a cracker. They rightly withdrew all their many source tarballs to check for malicious code. The old tarballs were quickly reinstated (presumably because they had backups from prior to when the cracker owned them) and also found to be free of malicious code. There are still some 500 of these newer tarballs for GNU to check and apparently they are doing it at a rate of 10-15 per day. libtool-1.5.tar.gz is one of those tarballs that has not yet been given a clean bill of health by GNU (see http://ftp.gnu.org/gnu/libtool/). Nevertheless, it has been packaged for debian unstable. There is some room for optimism that the tarball used to create that package does not have malicious code in it (since the older tarballs that have been checked do seem to be clean), but the cracker did have full control when that tarball was created and for many months afterward, and the downside (many Debian packages compromised that are built with libtool-1.5) could be severe indeed. Thus, wouldn't it be the right thing to do to withdraw the Debian unstable libtool-1.5 package until GNU has a chance to check the tarball? (And of course after the checked version is available, the tarball used to create the current package should be checked against it to make sure nothing malicious got propagated while the libtool-1.5 package was available). Note, I run debian stable myself, and I only happened to notice this possible libtool-1.5 security problem for Debian unstable by chance. Since there doesn't seem to be any discussion of this issue on this list (and no libtool bug reports about this issue) I thought I had better bring it up for discussion. Alan W. Irwin __ Alan W. Irwin email: [EMAIL PROTECTED] phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The possibility of malicious code in the Debian unstable libtool-1.5 package
On Tue, Aug 26, 2003 at 08:23:44AM -0700, Alan W. Irwin wrote: Thus, wouldn't it be the right thing to do to withdraw the Debian unstable libtool-1.5 package until GNU has a chance to check the tarball? (And of course after the checked version is available, the tarball used to create the current package should be checked against it to make sure nothing malicious got propagated while the libtool-1.5 package was available). Would it not be the right thing to simply run diff between the source in testing (assuming that predates the crack) and the one in unstable and look for suspicious code? It doesn't take somebody operating in an official GNU capacity to confirm that there's no malicious code there. noah pgp0.pgp Description: PGP signature
Re: The possibility of malicious code in the Debian unstablelibtool-1.5 package
On Tue, 2003-08-26 at 16:23, Alan W. Irwin wrote: As I am sure most of you on this list are aware, GNU recently discovered that their ftp file server was owned for many months by a cracker. Indeed, I was the one who did a bulk-check of the easy MD5 sums and posted it to the list :-) libtool-1.5.tar.gz is one of those tarballs that has not yet been given a clean bill of health by GNU (see http://ftp.gnu.org/gnu/libtool/). Nevertheless, it has been packaged for debian unstable. Untrue. The Debian package is actually Libtool 1.5.0a and is taken from their CVS repository, which wasn't compromised. The _orig.tar.gz *is* the potentially compromised one from the FTP site, however any compromise would be reverted back to the uncompromised CVS version by the .diff.gz[0] That aside, I've compared libtool-1.5.tar.gz to a checkout of the GNU CVS tree for that release, and there's no differences... as well as obviously manually reading the 1.5 - 1.5.0a diff before applying it. Unless cvs.gnu.org was also compromised by someone insane enough to rewrite RCS files by hand to hide the modification, libtool in unstable is safe :-) Scott [0] which also accidentally contains some .svn trees, oops! :) -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Re: The possibility of malicious code in the Debian unstablelibtool-1.5 package
On 26 Aug 2003, Scott James Remnant wrote: The Debian package is actually Libtool 1.5.0a and is taken from their CVS repository, which wasn't compromised. The _orig.tar.gz *is* the potentially compromised one from the FTP site, however any compromise would be reverted back to the uncompromised CVS version by the .diff.gz[0] That aside, I've compared libtool-1.5.tar.gz to a checkout of the GNU CVS tree for that release, and there's no differences... as well as obviously manually reading the 1.5 - 1.5.0a diff before applying it. Unless cvs.gnu.org was also compromised by someone insane enough to rewrite RCS files by hand to hide the modification, libtool in unstable is safe :-) I agree it takes extreme care to leave no tracks behind so it is fairly improbable that the cvs server was compromised. And even if an undetected crack occurred of that server, I agree it would take some effort to rewrite RCS files (although temporarily putting in a maliciously modified cvs server could do it). Thus, I agree with your judgement that restoring from cvs is safe to a fairly large degree. However, GNU have apparently decided not to restore from cvs since otherwise they should be able to proceed at a much faster rate than 10-15 restorations per day. Shouldn't debian follow their lead and be ultra-cautious also (especially with libtool since the downside is so severe if that app is compromised)? Alan __ Alan W. Irwin email: [EMAIL PROTECTED] phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The possibility of malicious code in the Debian unstablelibtool-1.5 package
On Tue, 2003-08-26 at 17:38, Alan W. Irwin wrote: On 26 Aug 2003, Scott James Remnant wrote: The Debian package is actually Libtool 1.5.0a and is taken from their CVS repository, which wasn't compromised. I agree it takes extreme care to leave no tracks behind so it is fairly improbable that the cvs server was compromised. And even if an undetected crack occurred of that server, I agree it would take some effort to rewrite RCS files (although temporarily putting in a maliciously modified cvs server could do it). Thus, I agree with your judgement that restoring from cvs is safe to a fairly large degree. However, GNU have apparently decided not to restore from cvs since otherwise they should be able to proceed at a much faster rate than 10-15 restorations per day. Shouldn't debian follow their lead and be ultra-cautious also (especially with libtool since the downside is so severe if that app is compromised)? My tracking of the libtool 1.5 branch of CVS predates the compromise, trust me, there's no naughty code in there. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Re: Looking for a simple SSL-CA package
- Original Message - From: Tarjei Huse [EMAIL PROTECTED] To: Noah L. Meyerhans [EMAIL PROTECTED]; debian-security@lists.debian.org Sent: Sunday, August 24, 2003 1:51 PM Subject: Re: Looking for a simple SSL-CA package I think I'll end up with pyca (www.pyca.org) as it seems to have most of these features in place. The other possibilities are openca which is IMHO to complicated for my needs and tinyca (that many on this list suggested) that doesn't (please correct me if I'm wrong) give me the finished scripts for importing certs in outlook, IE, Mozilla and other programs. If there are other alternatives out there, please let me know. Again, I thank you for your contributions. Tarjei Apologies if I am repeating someone else's points, I haven't followed the thread in depth. It sounds kind of kooky, but we have operated a CA for about 2 years, having about 400 users, using just openssl and a few hand turned scripts and a dynamic webpage. User info is maintained in MySQL, though we let openssl maintain the CA history in text files. The CA doesn't do any of the Outlook, IE, Mozilla etc importing - those programs do that, you just have to know what sort of certs to generate, and how to trigger the import processing on the client. We use a webpage and several variants of the XEnroll object for IE v 5.01-6.0 where IE generates the keypairs, and creates a CSR which gets posted to the webserver. We then sign the request and create a x-pkcs7-certificates [.p7b file] which is returned to the webserver for the user to download (they hit the Refresh button on the request page). There are some busted Office XP upgrade paths, for which we have to generate the keypair on our server in a PKCS12 format [.pfx file] - which we then make available to the user via the webpage. NS/Mozilla is easy - as per IE, we get the client to generate a CSR which gets posted to our webserver. We sign the certificate, x-x509-user-cert [.cct file] and copy it back to the webserver for the user to install. The only bugbear is that Mozilla succeeds silently, so you can't easily throw up a warning if the import failed for some reason [failure is rare]. Outlook will recognise your CA as an authority for secure pop and imap connections, if you import your self-signed CA cert in IE - just get your users to download your CA cert x-x509-ca-cert [.crt file] from a website, and click on Install Cert. Regards Jeff
unsubscribe
towards a taxonomy of Information Assurance (IA)
Fellow Information Security Professionals, Bottom line: I'd like your help in shaping a usable taxonomy of Information Assurance.* This taxonomy is part of my graduate studies, and will not be used for any commercial purposes. It will remain an open source open project. I am presently working on creating a taxonomy of information assurance, based on the three aspects of: (1) Information characteristics (2) Information states (3) Security countermeasures These three aspects of Information Assurance (IA) were highlighted by John McCumber [1] as well as a team of West Point researchers [2] as a component of works that define an integrated approach to security. I have also considered the works of Matt Bishop [3] in how to create a useful taxonomy. Within the next 6 months, I would like to create a taxonomy that graphically depicts the relationships of these three aspects. I will use an open source model whereby all of my findings results will be posted for public review and revision. My intent is that this taxonomy could be used by the academic community, industry, and government in improving the precision of communication used in discussing information assurance/security topics. I have searched the Internet widely for a taxonomy of Information Assurance, but I have not found anything that is sufficiently detailed for application with real world problems. I've posted my initial results to the following URL: http://www.sharp-ideas.net/ia/information_assurance.htm for comments and peer review. Cheers, Abe Usher [EMAIL PROTECTED] * Information assurance is defined as information operations that protect and defend information and information systems by ensuring their availability, integrity, authentication, confidentiality, and non-repudiation. This includes providing for restoration of information systems by incorporating protection, detection, and reaction capabilities. [1] McCumber, John. Information Systems Security: A Comprehensive Model. Proceedings 14th National Computer Security Conference. National Institute of Standards and Technology. Baltimore, MD. October 1991. [2] Maconachy, Victor, Corey Schou, Daniel Ragsdale, and Don Welch. A Model for Information Assurance: An Integrated Approach. Proceedings of the 2001 IEEE Workshop on Information Assurance and Security. U.S. Military Academy. West Point, NY. June 2001. [3] Bishop, Matt. A Critical Analysis of Vulnerability Taxonomies. Department of Computer Science, University of California. Davis, CA. September 1996.
[no subject]
Mike Lewis Business Systems Analyst Mississippi Band of Choctaw Indians dba Chahta Enterprise Enterprise Headquarters for our Wiring Harness Manufacturing Division Commercial Laundry Division Geospatial and Information Technology Division 390 Industrial Road Choctaw, MS 39350 601-656-7350 x 102 601-656-8785 - Fax
The possibility of malicious code in the Debian unstable libtool-1.5 package
As I am sure most of you on this list are aware, GNU recently discovered that their ftp file server was owned for many months by a cracker. They rightly withdrew all their many source tarballs to check for malicious code. The old tarballs were quickly reinstated (presumably because they had backups from prior to when the cracker owned them) and also found to be free of malicious code. There are still some 500 of these newer tarballs for GNU to check and apparently they are doing it at a rate of 10-15 per day. libtool-1.5.tar.gz is one of those tarballs that has not yet been given a clean bill of health by GNU (see http://ftp.gnu.org/gnu/libtool/). Nevertheless, it has been packaged for debian unstable. There is some room for optimism that the tarball used to create that package does not have malicious code in it (since the older tarballs that have been checked do seem to be clean), but the cracker did have full control when that tarball was created and for many months afterward, and the downside (many Debian packages compromised that are built with libtool-1.5) could be severe indeed. Thus, wouldn't it be the right thing to do to withdraw the Debian unstable libtool-1.5 package until GNU has a chance to check the tarball? (And of course after the checked version is available, the tarball used to create the current package should be checked against it to make sure nothing malicious got propagated while the libtool-1.5 package was available). Note, I run debian stable myself, and I only happened to notice this possible libtool-1.5 security problem for Debian unstable by chance. Since there doesn't seem to be any discussion of this issue on this list (and no libtool bug reports about this issue) I thought I had better bring it up for discussion. Alan W. Irwin __ Alan W. Irwin email: [EMAIL PROTECTED] phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __
Re: The possibility of malicious code in the Debian unstable libtool-1.5 package
On Tue, Aug 26, 2003 at 08:23:44AM -0700, Alan W. Irwin wrote: Thus, wouldn't it be the right thing to do to withdraw the Debian unstable libtool-1.5 package until GNU has a chance to check the tarball? (And of course after the checked version is available, the tarball used to create the current package should be checked against it to make sure nothing malicious got propagated while the libtool-1.5 package was available). Would it not be the right thing to simply run diff between the source in testing (assuming that predates the crack) and the one in unstable and look for suspicious code? It doesn't take somebody operating in an official GNU capacity to confirm that there's no malicious code there. noah pgpwhJqV4WpGy.pgp Description: PGP signature
Re: The possibility of malicious code in the Debian unstable libtool-1.5 package
On 26 Aug 2003, Scott James Remnant wrote: The Debian package is actually Libtool 1.5.0a and is taken from their CVS repository, which wasn't compromised. The _orig.tar.gz *is* the potentially compromised one from the FTP site, however any compromise would be reverted back to the uncompromised CVS version by the .diff.gz[0] That aside, I've compared libtool-1.5.tar.gz to a checkout of the GNU CVS tree for that release, and there's no differences... as well as obviously manually reading the 1.5 - 1.5.0a diff before applying it. Unless cvs.gnu.org was also compromised by someone insane enough to rewrite RCS files by hand to hide the modification, libtool in unstable is safe :-) I agree it takes extreme care to leave no tracks behind so it is fairly improbable that the cvs server was compromised. And even if an undetected crack occurred of that server, I agree it would take some effort to rewrite RCS files (although temporarily putting in a maliciously modified cvs server could do it). Thus, I agree with your judgement that restoring from cvs is safe to a fairly large degree. However, GNU have apparently decided not to restore from cvs since otherwise they should be able to proceed at a much faster rate than 10-15 restorations per day. Shouldn't debian follow their lead and be ultra-cautious also (especially with libtool since the downside is so severe if that app is compromised)? Alan __ Alan W. Irwin email: [EMAIL PROTECTED] phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __
Re: The possibility of malicious code in the Debian unstable libtool-1.5 package
On Tue, 2003-08-26 at 17:38, Alan W. Irwin wrote: On 26 Aug 2003, Scott James Remnant wrote: The Debian package is actually Libtool 1.5.0a and is taken from their CVS repository, which wasn't compromised. I agree it takes extreme care to leave no tracks behind so it is fairly improbable that the cvs server was compromised. And even if an undetected crack occurred of that server, I agree it would take some effort to rewrite RCS files (although temporarily putting in a maliciously modified cvs server could do it). Thus, I agree with your judgement that restoring from cvs is safe to a fairly large degree. However, GNU have apparently decided not to restore from cvs since otherwise they should be able to proceed at a much faster rate than 10-15 restorations per day. Shouldn't debian follow their lead and be ultra-cautious also (especially with libtool since the downside is so severe if that app is compromised)? My tracking of the libtool 1.5 branch of CVS predates the compromise, trust me, there's no naughty code in there. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Re: The possibility of malicious code in the Debian unstable libtool-1.5 package
On 26 Aug 2003, Scott James Remnant wrote: My tracking of the libtool 1.5 branch of CVS predates the compromise, trust me, there's no naughty code in there. Thanks for that strong public reassurance and the useful discussion that preceded it. Alan __ Alan W. Irwin email: [EMAIL PROTECTED] phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __
Re: Debian Stable server hacked
On Fri, Aug 22, 2003 at 06:35:37PM -0400, Phillip Hofmeister wrote: On Fri, 22 Aug 2003 at 10:32:27AM -0400, Matt Zimmerman wrote: It is often the case that the attacker doesn't know the exact location of structures in memory; there are techniques for finding out. I'm sure that the authors of PaX do not misrepresent it as complete protection. It's pointless to argue about it; it's clear that PaX provides some value in protection against security vulnerabilities, and I think it's also clear that because it will break many existing applications, it is not suitable for use by default. But there is no reason why a PaX-enabled kernel could not be provided as an option. All it needs is someone willing to do the work (hint, hint). I would be willing to maintain a grsec kernel image with PaX and temp. file symlink blocking if someone would be willing to sponsor it (hint, hint) I really do not have the time to sponsor you, but would like to see this happen. If you put together reasonable packages and ask on the mailing lists, I don't think you'd have a problem finding a sponsor. There are a number developers who are interested in this. -- - mdz
Re: Debian Stable server hacked
* Matt Zimmerman ([EMAIL PROTECTED]) wrote: On Fri, Aug 22, 2003 at 06:35:37PM -0400, Phillip Hofmeister wrote: I would be willing to maintain a grsec kernel image with PaX and temp. file symlink blocking if someone would be willing to sponsor it (hint, hint) I really do not have the time to sponsor you, but would like to see this happen. If you put together reasonable packages and ask on the mailing lists, I don't think you'd have a problem finding a sponsor. There are a number developers who are interested in this. I might be willing to sponsor it. Contact me off-list if interested. Stephen pgpsEdrw3Va80.pgp Description: PGP signature
Fw: Debian-security copy any DVD to a standart CD at home OZKrmIV
Title: vGbpJdd Hello, Debian-security! abTwaTv WATCH CNN Ka Ajw ANALYSIS NYTimes AFcBV 'Don't listen to' gossip MF
