[Full-Disclosure] Cisco IOS 12.2(4)XR
Hi, I need to evaluate Cisco IOS X-Release 12.2(4)XR (exactly S366CK9W5-12204XR,c3660-ik9w5-mz). Here is the download URL http://www.cisco.com/pcgi-bin/Software/Iosplanner/Planner-tool/iosplanner.cgi?majorRel=12.2 but the link seems broken and Cisco does not wish to support mentioned IOS anymore. I thought somebody may have kept a copy. Thanks, Behnam ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
[Full-Disclosure] Netscape Problems.
In a message on Bugtraq, Last Stage of Delirium wrote: (http://msgs.securepoint.com/cgi-bin/get/bugtraq0211/255.html) > We can understand why there was no response from Netscape since the > three[1][3][4] vulnerabilities affecting Netscape web browser were > submitted to the Netscape Bug Bounty program which entitles 1000 USD for > a security bug in Netscape Communicator to its founder. Netscape seems > to be another American company that does not seem to be fulfilling > public obligations made through company's web pages > (http://home.netscape.com/security/bugbounty.html). While we were > waiting for Netscape's reponse to our vulnerability report, Netscape > changed(!) Reward Guidelines of the Bug Bounty program so that now only > bugs in Netscape 7.x are rewarded (previously both latest 6.x and 4.8 > versions were taken into account). Nice move, huh ? You might want to see the September 13 email reference below, and then maybe you could still hold some hope out. Maybe. A little. Or something.) This email was written on Tuesday 26 November, 6.55pm NZDT. As of this time, I have yet to recieve any confirmation that I would be getting any of the offered Bug Bounty. I have been informed I am eligble, however, bash-2.04$ egrep '^From: [EMAIL PROTECTED]$' mail/Bugz|wc -l 90 bash-2.04$ 90 Messages related to the following bugs dated between List of bugs and bugzilla.mozilla.org bug names: PNG1 - 155222 - width integer overflow PNG2 - ?? - alpha size integer overflow JAR1 - 157646 - Incorrect uncompressed size causes heap corruption Javascript - 157652 - sort() and size integer overflow GIF- 157989 - 0 width GIF Another bug not mentioned. And I can't remember if I have told them about the integer overflow in the pop3 mail handler, mozilla/mailnews/local/src/nsPop3Protocol.cpp: ... PR_CALLOC(sizeof(Pop3MsgInfo) * m_pop3ConData->number_of_messages); ... where m_pop3ConData->number_of_messages is a server supplied value, and sizeof(Pop3MsgInfo) is 8. How would this be exploitable? Well, if someone offered free email with POP3 access, there would be at least some people who would take advantage of it. A malicious server could then potentially take over the running instance of Netscape/Mozilla. (gdb) print/u 8 * 536870912 $1 = 0 (gdb) If I told them about this, I never saw any email about it afterwards. (I believe this is similar to: http://online.securityfocus.com/bid/3164/discussion/ but I haven't looked at that bug, so I may be wrong.) Netscape story == Fixes: PNG1 & PNG2 were fixed with one extra check in 1.0.1/1.1 JAR1 is/will be fixed in Mozilla 1.2(beta?) Javascript potentially exploitable problem was fixed, however not shown to be definately exploitable, however that does not mean it definately is. (Look at the source and see if you can work out how to. Need to 'guess' where the sort is going to place things and need to cause the offsets it moves to be the places you need them to be.) (fixed 1.0.1/1.1) GIF has had exploit method released, fixed in Mozilla 1.0.1 and 1.1, I believe. The shellcode may be helpful. (The shellcode is not optimal, but at least it tends to work in a threaded environment.) (fixed 1.0.1/1.1(?)) Interesting parts of communications regarding these bugs. [Please note: some dates below may be approximate due to timezone differences in the headers. Sorry.] June 29 === Completed writeup of heap corruption in Netscape and Mozilla, via PNG. June 30 === Reported PNG via Netscape Security Bug form. July 1 == Bug added to bugzilla.mozilla.org [Bug 155222] Heap corruption in PNG library http://bugzilla.mozilla.org/show_bug.cgi?id=155222 July 7 == Notified Microsoft of potential problem in Javascript sort() method. (Netscape was notified on the same day, I believe.) July 9 == Microsoft replies with regard to Javascript. July 13 === Microsoft closes off on JS bug. Patch becomes available eventually, as threat was not seen as high by Microsoft. +++ Netscape informed of second PNG bug/exploit method. == Sent == Date: Sat, 13 Jul 2002 04:04:56 +1200 (NZST) From: zen-parse <[EMAIL PROTECTED]> To: Mitchell Stoltz <[EMAIL PROTECTED]> Subject: exploitable heap corruption via PNG Alpha data (Different section of code, however, similar root cause.) July 17 === Fix checked into 1.0.1 tree for bug 155222. (Initial PNG bug.) Notified Netscape for GIF zero width bug vuln. August 5 [An update for 155222] -- Additional Comments From [EMAIL PROTECTED] 2002-08-05 06:16 --- Since this bug was discussed publicly in the libpng mailing lists and is described and fixed publicly in libpng-1.2.4/1.0.14, perhaps it can be made a "public" Mozilla bug. August 10 = Emailed Mitchell Stoltz <[EMAIL PROTECTED]> with regards to resolution time for other PNG bug and jar bugs. August 12 = [Bug 157646] Possible heap corruption in libjar http://bug
[Full-Disclosure] MDKSA-2002:082 - Updated python packages fix local arbitrary code execution vulnerability
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mandrake Linux Security Update Advisory Package name: python Advisory ID:MDKSA-2002:082 Date: November 25th, 2002 Affected versions: 7.2, 8.0, 8.1, 8.2, 9.0, Single Network Firewall 7.2 Problem Description: A vulnerability was discovered in python by Zack Weinberg in the way that the execvpe() method from the os.py module uses a temporary file name. The file is created in an unsafe manner and execvpe() tries to execute it, which can be used by a local attacker to execute arbitrary code with the privilege of the user running the python code that is using this method. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-1119 http://mail.python.org/pipermail/python-dev/2002-August/027223.html http://python.org/sf/590294 Updated Packages: Linux-Mandrake 7.2: e9e016b6b07fc58997f02b78b299f105 7.2/RPMS/python-1.5.2-12.1mdk.i586.rpm f08129c7b43de40eb712b0a7d4a5554e 7.2/RPMS/python-devel-1.5.2-12.1mdk.i586.rpm 0e59d9f64e6f8be19f4e2dc73a2b2090 7.2/RPMS/python-docs-1.5.2-12.1mdk.i586.rpm d969562e109022071cf69515cf9146b9 7.2/RPMS/tkinter-1.5.2-12.1mdk.i586.rpm 411eb33a72870ba125b7331ab9f077a4 7.2/SRPMS/python-1.5.2-12.1mdk.src.rpm Mandrake Linux 8.0: 9e9c147b6260b731016be16837d2cd09 8.0/RPMS/python-2.0-9.1mdk.i586.rpm c3a0d50a5c4ef7fd374c9e7614c9a0c6 8.0/RPMS/python-devel-2.0-9.1mdk.i586.rpm c7c31e4986334484d470066b6c2db346 8.0/RPMS/python-docs-2.0-9.1mdk.i586.rpm 69a2f2e7d10fb885592d7b4943dcac61 8.0/RPMS/tkinter-2.0-9.1mdk.i586.rpm c24d21f1d7e7e454c2ce78d2ce84a015 8.0/SRPMS/python-2.0-9.1mdk.src.rpm Mandrake Linux 8.0/PPC: 8c35df120638c62d47f586d4faf702d4 ppc/8.0/RPMS/python-2.0-9.1mdk.ppc.rpm 4d54961b8e8cdc301719f42855c6e45c ppc/8.0/RPMS/python-devel-2.0-9.1mdk.ppc.rpm d9943638bf6d8ff59950faef4a832c48 ppc/8.0/RPMS/python-docs-2.0-9.1mdk.ppc.rpm 5f57afb7e9d2042200e8ecd84e83143e ppc/8.0/RPMS/tkinter-2.0-9.1mdk.ppc.rpm c24d21f1d7e7e454c2ce78d2ce84a015 ppc/8.0/SRPMS/python-2.0-9.1mdk.src.rpm Mandrake Linux 8.1: 47695f02d722a8a7393af449a556fcc7 8.1/RPMS/libpython2.2-2.2-9.1mdk.i586.rpm 3fcb8dfd92f1dfaa076a95f227fee87c 8.1/RPMS/libpython2.2-devel-2.2-9.1mdk.i586.rpm 0f2f801268d9348f93c67a96d4d0f9d7 8.1/RPMS/python-2.2-9.1mdk.i586.rpm b69396894c2575949718df77d781 8.1/RPMS/python-base-2.2-9.1mdk.i586.rpm 81ab8ba9cd85b0bea9029aac3ed0d652 8.1/RPMS/python-docs-2.2-9.1mdk.i586.rpm 339191d1e03b5961cc625d2e4996f15f 8.1/RPMS/tkinter-2.2-9.1mdk.i586.rpm d1ac7fa2119ec7c84d408027d44f8525 8.1/SRPMS/python-2.2-9.1mdk.src.rpm Mandrake Linux 8.1/IA64: f27d9c351d9a74b5ea431956b33796af ia64/8.1/RPMS/libpython2.2-2.2-9.1mdk.ia64.rpm ccc514a11b7906c2ca2a3d32b63cf85b ia64/8.1/RPMS/libpython2.2-devel-2.2-9.1mdk.ia64.rpm b80f7653eb52b8de5bcd1eac9b39a882 ia64/8.1/RPMS/python-2.2-9.1mdk.ia64.rpm 68e4333b0ab080c7bf441728d1f96544 ia64/8.1/RPMS/python-base-2.2-9.1mdk.ia64.rpm 6915e488de60562b3728fe7e476fd9a8 ia64/8.1/RPMS/python-docs-2.2-9.1mdk.ia64.rpm d1ac7fa2119ec7c84d408027d44f8525 ia64/8.1/SRPMS/python-2.2-9.1mdk.src.rpm Mandrake Linux 8.2: 22771586df09a081fdd8c00b84a01611 8.2/RPMS/libpython2.2-2.2-9.1mdk.i586.rpm 4649b5d23aeb0a0868c21a0950ef6166 8.2/RPMS/libpython2.2-devel-2.2-9.1mdk.i586.rpm 1aa805b1f870bcb8e042def0d1011719 8.2/RPMS/python-2.2-9.1mdk.i586.rpm 3adaec8a682f16962ba52c984fd6270c 8.2/RPMS/python-base-2.2-9.1mdk.i586.rpm 137abe1f02e02e89bf2b635b76d07892 8.2/RPMS/python-docs-2.2-9.1mdk.i586.rpm 107a60f5b00f477514038459801d156d 8.2/RPMS/tkinter-2.2-9.1mdk.i586.rpm d1ac7fa2119ec7c84d408027d44f8525 8.2/SRPMS/python-2.2-9.1mdk.src.rpm Mandrake Linux 8.2/PPC: abb56b161b156cac0cba992e470d98a9 ppc/8.2/RPMS/libpython2.2-2.2-9.1mdk.ppc.rpm c8848d308e18571eb43452ad5e57907f ppc/8.2/RPMS/libpython2.2-devel-2.2-9.1mdk.ppc.rpm 5a065c10e341216cb02516166d12cdfa ppc/8.2/RPMS/python-2.2-9.1mdk.ppc.rpm 5fb31cc3f167e4f0a1e813ed535ea0a8 ppc/8.2/RPMS/python-base-2.2-9.1mdk.ppc.rpm f82636adec1620a226fce4781a771c08 ppc/8.2/RPMS/python-docs-2.2-9.1mdk.ppc.rpm fd7d4732704cc5d65d3db31aadc30679 ppc/8.2/RPMS/tkinter-2.2-9.1mdk.ppc.rpm d1ac7fa2119ec7c84d408027d44f8525 ppc/8.2/SRPMS/python-2.2-9.1mdk.src.rpm Mandrake Linux 9.0: 68816873ca418b97541ab7b817659f6d 9.0/RPMS/libpython2.2-2.2.1-14.1mdk.i586.rpm b563b5a12f11f65463e21e5035b5bff6 9.0/RPMS/libpython2.2-devel-2.2.1-14.1mdk.i586.rpm 1fd791067dd84dc2f7ed0b9d1d67348d 9.0/RPMS/python-2.2.1-14.1mdk.i586.rpm 3e011ff7fb03797803b129341ff7f087 9.0/RPMS/python-base-2.2.1-14.1mdk.i58
[Full-Disclosure] MDKSA-2002:081 - Updated samba packages fix potential root compromise
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mandrake Linux Security Update Advisory Package name: samba Advisory ID:MDKSA-2002:081 Date: November 25th, 2002 Affected versions: 8.1, 8.2, 9.0 Problem Description: A vulnerability in samba versions 2.2.2 through 2.2.6 was discovered by the Debian samba maintainers. A bug in the length checking for encrypted password change requests from clients could be exploited using a buffer overrun attack on the smbd stack. This attack would have to crafted in such a way that converting a DOS codepage string to little endian UCS2 unicode would translate into an executable block of code. This vulnerability has been fixed in samba version 2.2.7, and the updated packages have had a patch applied to fix the problem. References: http://www.samba.org/samba/whatsnew/samba-2.2.7.html Updated Packages: Mandrake Linux 8.1: b10451e71a1ba27d45956f57fb203118 8.1/RPMS/samba-2.2.2-3.3mdk.i586.rpm 22a6f9977518bbe2923ec7d2f68a698e 8.1/RPMS/samba-client-2.2.2-3.3mdk.i586.rpm 74d59e5578aaa0a23e760c828a6d8688 8.1/RPMS/samba-common-2.2.2-3.3mdk.i586.rpm 6d6a2835fd6e21b4c93dbaa5fe6f2d13 8.1/RPMS/samba-doc-2.2.2-3.3mdk.i586.rpm 4c7511781a263f633cab5bf1831ad69b 8.1/SRPMS/samba-2.2.2-3.3mdk.src.rpm Mandrake Linux 8.1/IA64: 2456e2af90d2e71e877a16f2ff034c73 ia64/8.1/RPMS/samba-2.2.2-3.3mdk.ia64.rpm 66043b111988d82d2800763950ea07e3 ia64/8.1/RPMS/samba-client-2.2.2-3.3mdk.ia64.rpm 6954d750eae921eece5e1e2ece9c42e5 ia64/8.1/RPMS/samba-common-2.2.2-3.3mdk.ia64.rpm cf5545988b8d07299b776a25d6dc2e56 ia64/8.1/RPMS/samba-doc-2.2.2-3.3mdk.ia64.rpm 4c7511781a263f633cab5bf1831ad69b ia64/8.1/SRPMS/samba-2.2.2-3.3mdk.src.rpm Mandrake Linux 8.2: 5552fadd8509fc7222099f88dad0f5a9 8.2/RPMS/nss_wins-2.2.3a-10.1mdk.i586.rpm 58da182a9a84a02010ddaf939e97bc7c 8.2/RPMS/samba-2.2.3a-10.1mdk.i586.rpm 91dcff33758dca1ca9a4779186a6917d 8.2/RPMS/samba-client-2.2.3a-10.1mdk.i586.rpm ce98076728c73ca79b78fc9d69b94b47 8.2/RPMS/samba-common-2.2.3a-10.1mdk.i586.rpm 983c2de083b240971026bb054b449fde 8.2/RPMS/samba-doc-2.2.3a-10.1mdk.i586.rpm fe4c7a8ebedede8ac10ff98eac2b84a5 8.2/RPMS/samba-swat-2.2.3a-10.1mdk.i586.rpm ec00eed80e135dd79b56608bbd2c0574 8.2/RPMS/samba-winbind-2.2.3a-10.1mdk.i586.rpm 5677dee51659f50acee4e55346ca737d 8.2/SRPMS/samba-2.2.3a-10.1mdk.src.rpm Mandrake Linux 8.2/PPC: 32e41a8c06f1b5b24b13de0f65dfa3cc ppc/8.2/RPMS/nss_wins-2.2.3a-10.1mdk.ppc.rpm 275bf7b8a2792e11bf94dc24557f8ebc ppc/8.2/RPMS/samba-2.2.3a-10.1mdk.ppc.rpm 66232f77afcacc83090e3cf848717962 ppc/8.2/RPMS/samba-client-2.2.3a-10.1mdk.ppc.rpm 912ccb4cc81f89de6de871aa1c4833c0 ppc/8.2/RPMS/samba-common-2.2.3a-10.1mdk.ppc.rpm af73612d4ea52c4a391ca75afd0dae8b ppc/8.2/RPMS/samba-doc-2.2.3a-10.1mdk.ppc.rpm 2117cd7af96f6467c867faef73a425b6 ppc/8.2/RPMS/samba-swat-2.2.3a-10.1mdk.ppc.rpm ab0402b7173a04be1cbc6c415807b98a ppc/8.2/RPMS/samba-winbind-2.2.3a-10.1mdk.ppc.rpm 5677dee51659f50acee4e55346ca737d ppc/8.2/SRPMS/samba-2.2.3a-10.1mdk.src.rpm Mandrake Linux 9.0: 25b264e1b5ee43b26d861f5b5e07d7d2 9.0/RPMS/nss_wins-2.2.7-2.1mdk.i586.rpm 619a0506a84d25099ca0653be0f5fd3a 9.0/RPMS/samba-client-2.2.7-2.1mdk.i586.rpm d7ed710067f71285cc616fe07efd7753 9.0/RPMS/samba-common-2.2.7-2.1mdk.i586.rpm 2b5667097a398ef87e9e721c26bb613b 9.0/RPMS/samba-doc-2.2.7-2.1mdk.i586.rpm ff124b4103dd84e51f5be82dd9244b1f 9.0/RPMS/samba-server-2.2.7-2.1mdk.i586.rpm a7b976a81f59d7ce7111cb5f44d89bcd 9.0/RPMS/samba-swat-2.2.7-2.1mdk.i586.rpm 0859d8665e9d2ea2f1f96365a7456e3f 9.0/RPMS/samba-winbind-2.2.7-2.1mdk.i586.rpm b93cd8ca9319a628ee7015bbd5d2196e 9.0/SRPMS/samba-2.2.7-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 Plea
RE: [Full-Disclosure] PHC replies to criticism
Why don't you PHC freaks get a life. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of [EMAIL PROTECTED] Sent: Sunday, November 24, 2002 6:16 PM To: [EMAIL PROTECTED] Subject: [Full-Disclosure] PHC replies to criticism -BEGIN PGP SIGNED MESSAGE- Hello, In response to Len's administrivia... We have decided to avoid self-defeating personal vendettas on this list and focus on those critics of PHC who possess the ability to think clearly and make cogent arguments. Such critics include Paul Schmehl and Steve Manzuik, perhaps the only critics on this list who have displayed clarity of thought and the ability to make logical and relevant arguments against what we have said. No names will be mentioned here, but we will be ignoring the following classes of people: 1. Those paranoid schizophrenics who make outlandish conspiracy theory claims suggesting that PHC is a government project or that PHC has been influenced by the government. We're not sure if these people are serious, but anyway. The meds aren't meant to taste good. 2. Those weak-minded individuals who, as we have mentioned in a previous sermon, resort to nothing but ad hominem attacks such as "lamers," "scriptkids," "newbies," and so on -- attacks they can't back up with evidence when challenged, i.e. they ignore the challenge totally and throw out further unsubstantiated, vaporous drivel. This makes them look like stubborn intellectual midgets who are capable of nothing except baseless monologues. 3. Those people unable to focus on the points raised, but instead choose to go off on a tangent with their self-promotional rants about how they are reformed blackhats and such. The transparency of these people in their job hunting process is truly laughable. This is a really silly thing to note here, but one of these individuals who has been online since 1994 has called PHC "fresh bloods," when in actual fact the majority of PHC has been online since before then, as is clearly evident to anyone who researches old ezine releases and knows enough about PHC to make accurate connections. As if time online necessarily relates to "skillz" or other irrelevant crap, anyway. 4. People sending in "narc" logs that have been floating around for a long time, not realizing that they are actually doing us a favour in vindicating us of terrorism motives. Well, OK, we will mention one name: the fake 'nwonknu' who also appears to be the fake 'shiftee'. Do what you may, but you are welcome to email us and express your grievances against us. Don't read into this as a passive assimilation tactic, though. As an exercise to the reader, see if you can classify the expected replies to this post based on the classes outlined above. The person who posts the most accurate classification attempt will be awarded op status in #phrack (yay). PHC -BEGIN PGP SIGNATURE- Version: Hush 2.2 (Java) Note: This signature can be verified at https://www.hushtools.com/verify wlgEARECABgFAj3hX/QRHHBoY0BodXNobWFpbC5jb20ACgkQ0rw64nEc6GLidwCeIdQD vrHFRPAGR199hHQGOJ6c07cAoJjD4BnslhqHtTdj7GWDykpKI70X =ohf1 -END PGP SIGNATURE- Concerned about your privacy? Follow this link to get FREE encrypted email: https://www.hushmail.com/?l=2 ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] [PHC] Sermon #3 (w/ reply to Paul Schmehl & others)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 *yawn* Is noone capable of posting without making it personal? Ignoring all the venomous junk: You state that blackhats advocate non-disclosure, yet you omit the reasons _why_ they advocate it. These are the reasons I supplied in my earlier posts. Let me try and explain this frankly for you: Situation A - If there is a hole in a system which is deployed on a huge scale etc, and it is kept secret, the entire user base is at risk from criminal hackers, and these hackers are the only people aware of it. I have shown you already that blackhats disclose vulns among themselves and these things inevitably come into the hands of the blackhat masses. In case you hadnt noticed, script kiddies themselves are getting into vuln-dev these days and no doubt will find holes themselves and distribute them.. If someone gets hacked, the responsibility is not of the admin, who cannot possibly know the system he was sold as secure had a vuln. So the responsibility is moved onto the vendor. Now this may not be a bad thing, computing technology seems to be the only product which we _expect_ it to be broken and there is no such thing as liability of the vendor if they release something which is broken. However, is it a good idea to take responsibliity away from the administrator? Will this not make him lazy, *shrug* and say 'its not my problem, its out of my hands, nothing I can do". We all know the problems negligent admins cause for the internet as whole. Also, if you rely on vendors to discover and fix holes, then you can count on it that they WONT want to announce it in a timely fashion. How many corporations do you know that are willing to say "hey, we sold you a flawed and insecure product that puts your entire business at risk, and lied when we told you it was safe to use, sorry about that!". Summary - Everyone is vulnerable, only blackhats have the tools, people feel more uncertain about the supposed security of their systems. Vendors can keep vulns secret to protect their business image. Bottom line - People get hacked and there is nothing they can do about it. Situation B - Dealing with that same hole, the entire installed user base is still at risk until it is discovered and disclosed. Now if it is disclosed, not only do the criminal blackhats have the information, but the admins etc become aware of it too. This gives them the opportunity to patch it up. Any good admin should be keeping tracking of security issues with the systems he uses, and if someone fails to patch their machine and gets hacked, that is their problem. Anyone doing responsible full disclosure will always coordinate with vendors and allow them to create the fixes needed before releasing the vulnerability information. My only problem with full-disclosure, is that I feel it should be in the form of an advisory which describes the vuln adequately to allow people to be informed about how it affects them and how best to protect against it. Full disclosure in the form of ./hack tools is completely un-necessary and irresponsible, and if you cared to notice, most people doing full-disclosure in the form of ready to run tools happen to be blackhats. Look at GOBBLES activity this year for example. How many reputable security companies have you seen, doing full disclosure in the form of ./tools ? Summary - Everyone is made aware they have a vuln in their system, they are given the means to fix it as they are informed of it. Sure the information allows people to write their own attack for the vuln, but the fix is available at the same time, and is no doubt easier to install the patch than it is for a kiddie to write the exploit from an abstract advisory, so that risk is effectively mitigated. Bottom line - People still get hacked, but there is a fix available so they have the means to protect themselves. Responsibility for security breach after disclosure remains in the hands of the network administrator which is where it should be. Full-disclosure also reveals the tricks and techniques of the exploit coder, which in turn assists the people making vulnerable systems to clean up their act. I stand by everything I said in the posts where I spoke about the blackhats selfish criminal motivations, and if you dont like that, tough luck. I stand by full-disclosure as long as it isn't in the form of ready to use "Proof of concept" code. Responsible full-disclosure is working, before the security industry matured EVERYONE was insecure. Now MANY are secure. That has to be considered a positive improvement no? Euan PS, ever heard the story of the bug in the rug who spends his whole life wandering around in circles, and never gets to see the whole pattern of the rug he lives in? Also, various quotes such as "if crypto is outlawed, only criminals will have crypto" seem appropriate. - - Original Message - From: "sockz loves you" <[EMAIL PROTECTED]> To: "Euan Briggs" <[EMAIL PROTECTED]> Cc: <[EMAIL PROT
Re: [Full-Disclosure] [PHC] Sermon #3 (w/ reply to Paul Schmehl & others)
- Original Message - From: "Euan Briggs" <[EMAIL PROTECTED]> Date: Sat, 23 Nov 2002 00:52:30 -0500 To: <[EMAIL PROTECTED]> Subject: Re: [Full-Disclosure] [PHC] Sermon #3 (w/ reply to Paul Schmehl & others) > Sorry to tell you this PHC, but I know who the majority of you are > and where you originate from. OMG NO!!! does this mean that my real identity as a transvestite cross-gendered ex-felon stripper who never originated from boston but really comes from a shell that was hatched in the ocean deep has been made public?! oh the embarassment!!! how will the hacker world ever take me seriously again!?! mr euan briggs, PHC isn't just the #phrack@EFnet ops. there are members of PHC who aren't opped on #phrack, some who don't even visit the channel. some who dont even bother with irc like you and i do. but seriously, i'd like to know what you know about me, and where i "originate from". i'm comfortable with you revealing this to the list or anywhere else for that matter. my identity is hardly something of a secret these days, but i'm fairly certain you remain without any clue. > My work with Snosoft does not mark my entry into the field. To be > frank, the reason I entered the whitehat arena, is because I am > appalled at what has happened to the blackhat scene. I am appalled by > the motives and attitudes of people such as PHC. I am appalled by the > behaviour of people like you. I have a conscience and a sense of > responsibility, towards my fellow human beings and our society. I > want the world to be a better place. I don't see working for the > security industry as some sort of "betrayal" of my blackhat roots, I > see it as making a -positive- contribution to society. I see it as > paying my debt to society, for the years I spent as a blackhat. > Entering the industry was a natural progression. I dont get a kick > out of crime, it only brings guilt and it is a rejection of the > society that nurtured you, human society which you owe your life to. if this is the case then what have you actually done about it? you constantly whine and gripe about how #phrack is so "bad and evil and omg stop them!!" but so far your actions to stop #phrack have amounted to zilch, nada, nothing. if you are so eager to talk about how great you are and how right you are, then why not give us some evidence as to why we should believe you. if you're not prepared to show evidence of malicious activities against #phrack or anyone else then shut up about your "blackhat roots" and your "debt to society". i doubt you ever were a blackhat, as you have consistantly shown a lack of skill to back up the lies you tell. > You claim to "hate" the security industry, because you believe they > are exploiting hackers and their world. Unless you yourselfs are > genuinely being exploited, I would say this part of your rather > contradictory manifesto its nothing more than a thin veneer of > justification for your delinquent attitudes. As I said in my last > post, I think you are just pissed off that you have a motivated and > well funded competitor (the industry), and people like you helped > create it. *snip* i cant speak for everyone who's against the security industry, just myself. so far my ideology in this whole mess has evolved. as i expanded my investigation into what the problem actually is, i realised that the term "anti-security industry" didn't really fit me, as i was more about changing the current system for the better... not the worse. like you and just about everyone else on this list i feel a degree of social responsibility when it comes to the matter. but unlike yourself i am not so resistant to change, and the cost of that change. we're learning as we go along here, just like anyone else. plz dont take words that were uttered in the heat of spirited patriotism to be the basis of our arguments. *snap* > You claim to be advocating non-disclosure because you believe it will > increase security, yet at the same time you claim to be blackhat > (implication = criminal) hackers. It doesnt add up. *sigh* i've tried to explain this so many times before. yet again i attempt to simplify everything without making too broad an assumption... yet again do i explain this: blackhat ~= person who advocates non-disclosure. hacks computers. doesn't brag security ~= the likelihood of a system withstanding an attack. at the moment many many ppl have ready access to information on how to compromise security. but a person can only secure their own system. this means that many ppl pose a security risk that few ppl can actually manage. (strong offence versus weak defence) non-disclosure solves this problem. if fewer ppl know about hacks (because blackhats dont talk about them) then fewer systems are threatened because the ratio of "attackers:admins" is reduced. PLEASE, try and think about it for yourself instead of trying to find all the faults in what i've said. just take a good look with an open and rat
[Full-Disclosure] [RHSA-2002:264-05] New kernel 2.2 packages fix local denial of service issue
- Red Hat, Inc. Red Hat Security Advisory Synopsis: New kernel 2.2 packages fix local denial of service issue Advisory ID: RHSA-2002:264-05 Issue date:2002-09-23 Updated on:2002-11-25 Product: Red Hat Linux Keywords: bugtraq DoS Cross references: Obsoletes: RHSA-2002:210 - 1. Topic: The kernel in Red Hat Linux 6.2 and 7 is vulnerable to a local denial of service attack. 2. Relevant releases/architectures: Red Hat Linux 6.2 - i386, i586, i686 Red Hat Linux 7.0 - i386, i586, i686 3. Problem description: The Linux kernel handles the basic functions of the operating system. A vulnerability in the Linux kernel has been discovered in which a non-root user can cause the machine to freeze. This kernel addresses the vulnerability. Note: This bug is specific to the x86 architecture kernels only, and does not affect other architectures. All users of Red Hat Linux 6.2 and 7 should upgrade to these errata packages, which are not vulnerable to this issue. Thanks go to Christopher Devine for reporting the vulnerability on bugtraq, and Petr Vandrovec for being the first to supply a fix to the community. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. The procedure for upgrading the kernel is documented at: http://www.redhat.com/support/docs/howto/kernel-upgrade/kernel-upgrade.html Please read the directions for your architecture carefully before proceeding with the kernel upgrade. Please note that this update is also available via Red Hat Network. Many people find this to be 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. Note that you need to select the kernel explicitly on default configurations of up2date. 5. RPMs required: Red Hat Linux 6.2: SRPMS: ftp://updates.redhat.com/6.2/en/os/SRPMS/kernel-2.2.22-6.2.3.src.rpm i386: ftp://updates.redhat.com/6.2/en/os/i386/kernel-smp-2.2.22-6.2.3.i386.rpm ftp://updates.redhat.com/6.2/en/os/i386/kernel-2.2.22-6.2.3.i386.rpm ftp://updates.redhat.com/6.2/en/os/i386/kernel-BOOT-2.2.22-6.2.3.i386.rpm ftp://updates.redhat.com/6.2/en/os/i386/kernel-ibcs-2.2.22-6.2.3.i386.rpm ftp://updates.redhat.com/6.2/en/os/i386/kernel-utils-2.2.22-6.2.3.i386.rpm ftp://updates.redhat.com/6.2/en/os/i386/kernel-pcmcia-cs-2.2.22-6.2.3.i386.rpm ftp://updates.redhat.com/6.2/en/os/i386/kernel-doc-2.2.22-6.2.3.i386.rpm ftp://updates.redhat.com/6.2/en/os/i386/kernel-headers-2.2.22-6.2.3.i386.rpm ftp://updates.redhat.com/6.2/en/os/i386/kernel-source-2.2.22-6.2.3.i386.rpm i586: ftp://updates.redhat.com/6.2/en/os/i586/kernel-smp-2.2.22-6.2.3.i586.rpm ftp://updates.redhat.com/6.2/en/os/i586/kernel-2.2.22-6.2.3.i586.rpm i686: ftp://updates.redhat.com/6.2/en/os/i686/kernel-enterprise-2.2.22-6.2.3.i686.rpm ftp://updates.redhat.com/6.2/en/os/i686/kernel-smp-2.2.22-6.2.3.i686.rpm ftp://updates.redhat.com/6.2/en/os/i686/kernel-2.2.22-6.2.3.i686.rpm Red Hat Linux 7.0: SRPMS: ftp://updates.redhat.com/7.0/en/os/SRPMS/kernel-2.2.22-7.0.3.src.rpm i386: ftp://updates.redhat.com/7.0/en/os/i386/kernel-smp-2.2.22-7.0.3.i386.rpm ftp://updates.redhat.com/7.0/en/os/i386/kernel-2.2.22-7.0.3.i386.rpm ftp://updates.redhat.com/7.0/en/os/i386/kernel-BOOT-2.2.22-7.0.3.i386.rpm ftp://updates.redhat.com/7.0/en/os/i386/kernel-ibcs-2.2.22-7.0.3.i386.rpm ftp://updates.redhat.com/7.0/en/os/i386/kernel-utils-2.2.22-7.0.3.i386.rpm ftp://updates.redhat.com/7.0/en/os/i386/kernel-pcmcia-cs-2.2.22-7.0.3.i386.rpm ftp://updates.redhat.com/7.0/en/os/i386/kernel-doc-2.2.22-7.0.3.i386.rpm ftp://updates.redhat.com/7.0/en/os/i386/kernel-source-2.2.22-7.0.3.i386.rpm i586: ftp://updates.redhat.com/7.0/en/os/i586/kernel-smp-2.2.22-7.0.3.i586.rpm ftp://updates.redhat.com/7.0/en/os/i586/kernel-2.2.22-7.0.3.i586.rpm i686: ftp://updates.redhat.com/7.0/en/os/i686/kernel-enterprise-2.2.22-7.0.3.i686.rpm ftp://updates.redhat.com/7.0/en/os/i686/kernel-smp-2.2.22-7.0.3.i686.rpm ftp://updates.redhat.com/7.0/en/os/i686/kernel-2.2.22-7.0.3.i686.rpm 6. Verification: MD5 sum Package Name -- 8c93dac15cbb3162f4cde7c0c0de5643 6.2/en/os/SRPMS/kernel-2.2.22-6.2.3.src.rpm a9b510b4ffca3e7bf643a46f99ee749f 6.2/en/os/i386/kernel-2.2.22-6.2.3.i386.rpm 5c08d5ac6ffebde931cc924914bf4f10 6.2/en/os/i386/kernel-BOOT-2.2.22-6.2.3.i386.rpm d417601fb70f93e159a10cf5a9e6e21b 6.2/en/os/i386/kernel-doc-2.2.22-6.2.3.i386.rpm 436d4c050116d0feb910bd93307797f2 6.2/en/os/i386/kernel-headers-2.2.22-6.2.3.i386.rpm 9c55348902c8a8f307be174c4602f59d 6.2/en/os/i386/kernel-ibcs-2.2.22-6.2.3.i386.rpm 6d3
[Full-Disclosure] SuSE Security Announcement: pine (SuSE-SA:2002:046)
-BEGIN PGP SIGNED MESSAGE- __ SuSE Security Announcement Package:pine Announcement-ID:SuSE-SA:2002:046 Date: Monday, Nov 25th 2002 10:30 MEST Affected products: 7.1, 7.2, 7.3, 8.0, 8.1 SuSE Linux Database Server SuSE eMail Server 3.1 SuSE eMail Server III SuSE Firewall Adminhost VPN SuSE Linux Admin-CD for Firewall SuSE Firewall on CD 2 - VPN SuSE Firewall on CD 2 SuSE Linux Enterprise Server for S/390 SuSE Linux Connectivity Server SuSE Linux Enterprise Server 7 for IA32 SuSE Linux Office Server Vulnerability Type: remote denial-of-service Severity (1-10):4 SuSE default package: yes (7.1 - 8.0) no (8.1) Cross References: none Content of this advisory: 1) security vulnerability resolved: - heap buffer overflow while parsing mail address problem description, discussion, solution and upgrade information 2) pending vulnerabilities, solutions, workarounds: - sparc distribution - WindowMaker 3) standard appendix (further information) __ 1) problem description, brief discussion, solution, upgrade information Pine, Program for Internet News and Email, is a well known and widely used eMail client. While parsing and escaping characters of eMail addresses pine does not allocate enough memory for storing the escaped mailbox part of an address. This results in a buffer overflow on the heap that will make pine crash. The offending eMail can just be deleted manually or by using another mail user agent. A possible temporary workaround is to filter the respective header lines by a mail delivery agent (such as procmail). 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. Intel i386 Platform: SuSE-8.1: ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/i586/pine-4.44-224.i586.rpm 8c32d5571d7488e31f693a884dedb81e patch rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/i586/pine-4.44-224.i586.patch.rpm 467b8b318958b0ead3f30fa7b1f5a9a0 source rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/src/pine-4.44-224.src.rpm 9b1ff436719cf9752cda3ddd711e80a7 SuSE-8.0: ftp://ftp.suse.com/pub/suse/i386/update/8.0/n1/pine-4.44-222.i386.rpm 01d9e82164a5ce4037b84be1b2ed4228 patch rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/8.0/n1/pine-4.44-222.i386.patch.rpm 162c4265909af7805f7aeaf3e12e8763 source rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/8.0/zq1/pine-4.44-222.src.rpm d724e02b1ea3783e5bfb01ae9728d7cf SuSE-7.3: ftp://ftp.suse.com/pub/suse/i386/update/7.3/n1/pine-4.33-266.i386.rpm 140c58adf7d0b2113d5b20de67e2 source rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/7.3/zq1/pine-4.33-266.src.rpm 100c86e88ce357b0efacf7dfe2ab592c SuSE-7.2: ftp://ftp.suse.com/pub/suse/i386/update/7.2/n1/pine-4.33-266.i386.rpm bd44232250b3def07cab81064dad11f2 source rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/7.2/zq1/pine-4.33-266.src.rpm e28daa1f2d66135fcf5951c9b2dc19be SuSE-7.1: ftp://ftp.suse.com/pub/suse/i386/update/7.1/n1/pine-4.33-263.i386.rpm 9bdd3394336a786b0711b8e98ab4a268 source rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/7.1/zq1/pine-4.33-263.src.rpm 630478b751a24e86c52fe645be9365c4 Sparc Platform: SuSE-7.3: ftp://ftp.suse.com/pub/suse/sparc/update/7.3/n1/pine-4.33-97.sparc.rpm 5187b311c27f043178a12ae186d228a6 source rpm(s): ftp://ftp.suse.com/pub/suse/sparc/update/7.3/zq1/pine-4.33-97.src.rpm 9616303edadfd899785f3ac12d2dc02a AXP Alpha Platform: SuSE-7.1: ftp://ftp.suse.com/pub/suse/axp/update/7.1/n1/pine-4.33-85.alpha.rpm f5155d79236e3ec15c463f586f731c17 source rpm(s): ftp://ftp.suse.com/pub/suse/axp/update/7.1/zq1/pine-4.33-85.src.rpm 75365b21b97c8a2f722d95491f62d305 PPC Power PC Platform: SuSE-7.3: ftp://ftp.suse.com/pub/suse/ppc/u
Re: [Full-Disclosure] PHC replies to criticism
On Sun, 24 Nov 2002, Ian Eyberg wrote:
[...]
> bullshit from kids whose only positive sign, so far as shown forth on
> this list, that they can speak eloquently (oohh.. fancy word, maybe
> that'll show em that I can 0wn their box). Everyone knows your point of
> view on things so shut up and hop back on irc and go root some boxen.
Why do you resort to argumentum ad hominem? You lack any valid arguments?
--- anakata <[EMAIL PROTECTED]>, Corpus Hypercubus
http://www.anakata.hack.se, IRC: {ef,irc,dal,slash}net, regular of #hack.se/efnet
Cogito, ergo infestus sum. [I think, therefore I am dangerous.]
___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
