From pete at isecom.org Tue Jul 3 09:47:44 2007 From: pete at isecom.org (Pete Herzog) Date: Tue, 03 Jul 2007 15:47:44 +0200 Subject: [Dailydave] TPM attacks Message-ID: <468A5380.7070304@isecom.org> Hi, Following the thread about the BH US presentation on the TPMkit (http://www.nvlabs.in/?q=node/32) being canceled, the discussion has entered on the internal list now at www.opentc.net. The idea there is to build a secure and trusted system using the TPM, virtualization, and open source software. A good portion of that process requires security testing of all trusted system components including the TPM software. So talk of such things like the TPMkit are apt to pop up. Apparently, there is a TPM attack at the boot process and from the opentc mailing list the following papers are mentioned: https://www.cosic.esat.kuleuven.be/publications/article-591.pdf http://os.inf.tu-dresden.de/papers_ps/kauer07-oslo.pdf So there is definite truth behind the proposed concept unfortunately it was already public knowledge. Maybe they had something else in mind? What makes me suspicious is the pop-star-like hype of their announcement about TPMkit equating the TPM to DRM in an attempt to make a flashier announcement. Sincerely, -pete. -- Pete Herzog - Managing Director - pete at isecom.org ISECOM - Institute for Security and Open Methodologies www.isecom.org - www.osstmm.org www.hackerhighschool.org - www.isestorm.org From mwollenweber at gmail.com Tue Jul 3 10:23:55 2007 From: mwollenweber at gmail.com (matthew wollenweber) Date: Tue, 3 Jul 2007 10:23:55 -0400 Subject: [Dailydave] iPhone Roadblock In-Reply-To: <4689F94F.8010800@cern.ch> References: <42210a440706301828u10a5d8eer688a381b96f604f5@mail.gmail.com> <4689F94F.8010800@cern.ch> Message-ID: <42210a440707030723m29238e0p27a91d311e86cac6@mail.gmail.com> Actually the guys over at: http://iphone.fiveforty.net/wikiare pretty far along of mounting the iPhone. The can read a files from a sandbox setup on the phone for iTunes. I believe they're hooking the iTunes dlls being used and REing a basic interface. Also, I haven't heard of anyone doing serious work regarding loading unofficial firmware. I'm sure that's a route people may consider, but everyone seems happy with the iPhone and just want it to do more and be more open. Reinventing the wheel by writing new firmware seems like a lose-lose situation. On 7/3/07, Robert Clark wrote: > > matthew wollenweber wrote: > > I'm one of the lucky (or possibly crazy) people that managed to get an > > iPhone yesterday. If you're curious, I'm very happy with it so far. I'm > not > > an Apple nut that buys all things Apple, but after years of > "smartphones" > > that never seemed quite right, the iPhone really seems to have hit the > > mark. > > My biggest worry was that it used Edge rather than 3G. While at some > points > > this is noticeable, the caching and windowing mechanisms really make up > for > > the difference. On the whole it's the best smartphone experience I've > had. > > But you can read all the reviews in a more appropriate forum... > > > > I'm really interested in hacking up my iPhone. Anything with a *nix OS > > underneath is just too tempting to leave alone. Unfortunately Apple > threw a > > curve ball that's outside my skill set. The iPhone doesn't mount as a > > harddrive. I couldn't find any options in iTunes and in linux I only > got: > > > > Jun 30 21:25:42 lothlorien kernel: usb 1-4: new full speed USB device > using > > ehci_hcd and address 15 > > Jun 30 21:25:42 lothlorien kernel: usb 1-4: Product: iPhone > > Jun 30 21:25:42 lothlorien kernel: usb 1-4: Manufacturer: Apple Inc. > > Jun 30 21:25:42 lothlorien kernel: usb 1-4: SerialNumber: XYZ123456789 > > Jun 30 21:25:42 lothlorien kernel: usb 1-4: configuration #1 chosen from > 3 > > choices > > > > USB device drivers aren't my thing. Anyone have any suggestions on how > to > > get the thing mounted or to go about figuring out how to do so? > > > > Thanks for any help. > > > > Its incredibly unlikely that you will be able to mount the underlying OS > filesystem in any way or form. > > I expect (as is often the case) the most viable way to hack the iPhone > will be using its official firmware upgrading system and a hacked > firmware which poses as an official one. > > Without doubt, we are in for some interesting discoveries. > > -- > /** > * Robert Clark > ** > * Technical Student ALICE/DAQ > * Software Engineer CERN PH/AID > */ > -- Matthew Wollenweber mwollenweber at gmail.com | mjw at cyberwart.com www.cyberwart.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20070703/7ed47b66/attachment.htm From dr at kyx.net Tue Jul 3 23:34:56 2007 From: dr at kyx.net (Dragos Ruiu) Date: Tue, 3 Jul 2007 20:34:56 -0700 Subject: [Dailydave] PacSec 2007 Call For Papers (Nov. 29/30, deadline July 27) Message-ID: <200707032034.57410.dr@kyx.net> PacSec CALL FOR PAPERS World Security Pros To Converge on Japan TOKYO, Japan -- To address the increasing importance of information security in Japan, the best known figures in the international security industry will get together with leading Japanese researchers to share best practices and technology. The most significant new discoveries about computer network hack attacks will be presented at the fifth annual PacSec conference to be discussed. The PacSec meeting provides an opportunity for foreign specialists to be exposed to Japanese innovation and markets and collaborate on practical solutions to computer security issues. In a relaxed setting with a mixture of material bilingually translated in both English and Japanese the eminent technologists can socialize and attend training sessions. Announcing the opportunity to submit papers for the PacSec 2007 network security training conference. The conference will be held November 29-30th in Tokyo. The conference focuses on emerging information security tutorials - it will be a bridge between the international and Japanese information security technology communities.. Please make your paper proposal submissions before July 27th, 2007. Slides for the papers must be submitted by October 1st 2007. The conference is November 29th and 30th 2007, presenters need to be available in the days before to meet with interpreters. A some invited papers have been confirmed, but a limited number of speaking slots are still available. The conference is responsible for travel and accomodations for the speakers. If you have a proposal for a tutorial session then please email a synopsis of the material and your biography, papers and, speaking background to secwest07 [at] pacsec.jp . Tutorials are one hour in length, but with simultaneous translation should be approximately 45 minutes in English, or Japanese. Only slides will be needed for the October paper deadline, full text does not have to be submitted. The PacSec conference consists of tutorials on technical details about current issues, innovative techniques and best practices in the information security realm. The audiences are a multi-national mix of professionals involved on a daily basis with security work: security product vendors, programmers, security officers, and network administrators. We give preference to technical details and education for a technical audience. The conference itself is a single track series of presentations in a lecture theater environment. The presentations offer speakers the opportunity to showcase on-going research and collaborate with peers while educating and highlighting advancements in security products and techniques. The focus is on innovation, tutorials, and education instead of product pitches. Some commercial content is tolerated, but it needs to be backed up by a technical presenter - either giving a valuable tutorial and best practices instruction or detailing significant new technology in the products. Paper proposals should consist of the following information: 1) Presenter, and geographical location (country of origin/passport) and contact info (e-mail, postal address, phone, fax). 2) Employer and/or affiliations. 3) Brief biography, list of publications and papers. 4) Any significant presentation and educational experience/background. 5) Topic synopsis, Proposed paper title, and a one paragraph description. 6) Reason why this material is innovative or significant or an important tutorial. 7) Where else has this material been presented or submitted? 8) Optionally, any samples of prepared material or outlines ready. Please forward the above information to secwest07 [at] pacsec.jp to be considered for placement on the speaker roster. cheers, --dr P.s. Some other dates of interest are announced: CanSecWest 2008 March 19-21 see http://cansecwest.com EUSecWest 2008 May 21/22 see http://eusecwest P.P.S. Also as a friendly reminder, CCC Camp is Aug 8 -12 2008, see http://events.ccc.de/camp/2007/Intro (Hi Julia et al...) Happy Independence Day and Canada Day, -- World Security Pros. Cutting Edge Training, Tools, and Techniques Tokyo, Japan November 29/30 - 2007 http://pacsec.jp pgpkey http://dragos.com/ kyxpgp From dave.aitel at gmail.com Thu Jul 5 08:26:30 2007 From: dave.aitel at gmail.com (Dave Aitel) Date: Thu, 5 Jul 2007 08:26:30 -0400 Subject: [Dailydave] Syscan fun Message-ID: http://freecursor.blogspot.com/ Someone's doing a running commentary on Syscan. :> It's cool to get the blow-by-blow from lots of different people on things like this. Everyone sees something different. -dave -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20070705/fd6c136f/attachment.htm From dave.aitel at gmail.com Thu Jul 5 19:13:14 2007 From: dave.aitel at gmail.com (Dave Aitel) Date: Thu, 5 Jul 2007 19:13:14 -0400 Subject: [Dailydave] 400 thousand dollars worth of lunch at Syscan 07 Message-ID: Today at lunch: 1300 Singapore time Title of Talk: Detecting BluePill Speaker: Edgar Barbosa (COSEINC) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20070705/ec5bac6b/attachment.htm From dave at immunityinc.com Fri Jul 6 09:39:42 2007 From: dave at immunityinc.com (Dave Aitel) Date: Fri, 06 Jul 2007 09:39:42 -0400 Subject: [Dailydave] .Net 0day? Message-ID: <468E461E.4090103@immunityinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 http://bp3.blogger.com/_aU4sjfnl3RY/Ro4EjK53JyI/AAAAAAAAAEM/DSWoKCXxXFI/s1600-h/P7060093.JPG Does anyone want to speculate as to the 0day? I assume putting %00%00 inside strings isn't it? :> Ooh, what about %u0000? :> Does mono have the same bug? Are they bug for bug compliant? - -dave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGjkYaB8JNm+PA+iURAr44AJwLW22PQPWf47cv5HMFYbmYHpEeuQCgiioy udDaIwcdkSkTsO35t1CrFqo= =X1a3 -----END PGP SIGNATURE----- From cmiller at securityevaluators.com Fri Jul 6 11:56:47 2007 From: cmiller at securityevaluators.com (Charles Miller) Date: Fri, 6 Jul 2007 10:56:47 -0500 Subject: [Dailydave] (no subject) Message-ID: Have you guys seen the public auction site selling 0-days: http://www.wslabi.com/wabisabilabi/initPublishedBid.do? Its probably not a good idea to give out so much information about the vulnerabilities. The Squirrelmail GPG Plugin one says its a command injection vulnerability. Shouldn't be too hard to rediscover that. Looking at it for 10 minutes, it looks like the exec in gpg_sign_attachment() where shell meta characters are in $passphrase. I'm too lazy to install it and check. I guess I could pay 1750 euros and find out! The MKPortal one looks pretty easy to find too. Its nice for someone to point these bugs out so we can go look for them! Probably not the smartest way to run the site... Charlie From dnm at pobox.com Fri Jul 6 13:01:12 2007 From: dnm at pobox.com (Dan Moniz) Date: Fri, 06 Jul 2007 13:01:12 -0400 Subject: [Dailydave] (no subject) In-Reply-To: References: Message-ID: <468E7558.7020604@pobox.com> Charles Miller wrote: > Have you guys seen the public auction site selling 0-days: Yep. A friend was kind enough to alert me about it a couple days ago. > http://www.wslabi.com/wabisabilabi/initPublishedBid.do? > > Its probably not a good idea to give out so much information about > the vulnerabilities. The Squirrelmail GPG Plugin one says its a > command injection vulnerability. Shouldn't be too hard to rediscover > that. Looking at it for 10 minutes, it looks like the exec in > gpg_sign_attachment() where shell meta characters are in > $passphrase. I'm too lazy to install it and check. I guess I could > pay 1750 euros and find out! The MKPortal one looks pretty easy to > find too. > > Its nice for someone to point these bugs out so we can go look for them! > > Probably not the smartest way to run the site... Have you seen the Press Release? Some choice examples, comments inline: "The exchange will become a global database of every IT security research ever found." Ambitious, to say the least. "Recently it was reported that although researchers had analyzed a little more than 7,000 publicly disclosed vulnerabilities last year, the number of new vulnerabilities found in code could be as high as 139,362 per year. Our intention is that the marketplace facility on WSLabi will enable security researchers to get a fair price for their findings and ensure that they will no longer be forced to give them away for free or sell them to cyber-criminals." That's an awfully precise number, and the fact that it would be that exact upper bound year after year is amazing! Who knew variance didn't exist in exploit discovery? "Researchers can submit their findings to the exchange once they have registered. WSLabi will then verify the research by analyzing and replicating it at their independent testing laboratories." Begs obvious questions about verifying high-value exploits on systems WSLabi doesn't have and can't procure... let alone the more mundane but crucial questions of what WSLabi does with exploits once they've verified them. "WSLabi will also help researchers to design the best business model (e.g. selling schemes, starting selling price etc.) which will enable them to maximize the value of their findings. For example, a piece of research that would currently sell to one company on an exclusive basis for $300 - $1000 could sell for ten to twenty times more than this amount using the portal." Business planning for exploit sales as a value-added service? And they're going to do this for every exploit offered on the site? What do they get out of it? What's their rational actor basis for this? "Both researchers and buyers will have to identify themselves to WSLabi to ensure they are legitimate. Researchers cannot submit security research material which comes from an illegal source or activity. Buyers will also be carefully vetted before being granted access to the auction platform so that the risk of selling the right stuff to the wrong people is minimized. The marketplace will be free to use for the first six months for both researchers and buyers." DUN DUN DUN! This will certainly constrain their goal of being a "global database of every IT security research ever found". While it makes sense from a legitimate business perspective (who wants to deal with criminals?), they're sending a mixed message by advocating a supposedly open "marketplace" with all sorts of weird rules and oversight. I don't necessarily think that's bad, but it's at cross purposes with what their saying. I think there's some misunderstanding of basic economics, the exploit development landscape, or apparently legitimate security research at work here. Probably all three. -- Dan Moniz [http://pobox.com/~dnm/] From matt at use.net Fri Jul 6 13:59:30 2007 From: matt at use.net (Matt) Date: Fri, 6 Jul 2007 10:59:30 -0700 (PDT) Subject: [Dailydave] .Net 0day? In-Reply-To: <468E461E.4090103@immunityinc.com> References: <468E461E.4090103@immunityinc.com> Message-ID: On Fri, 6 Jul 2007, Dave Aitel wrote: > http://bp3.blogger.com/_aU4sjfnl3RY/Ro4EjK53JyI/AAAAAAAAAEM/DSWoKCXxXFI/s1600-h/P7060093.JPG > > Does anyone want to speculate as to the 0day? I assume putting %00%00 > inside strings isn't it? :> Ooh, what about %u0000? :> > > Does mono have the same bug? Are they bug for bug compliant? As for finding bugs in mono, here's a big clue: Do your fuzzing of ASP.NET apps while running mono itself under valgrind. There's a valgrind suppressions file in mono/data/mono.supp to filter out the false positives generated by libgc. Luis and I will be talking about combining fuzzing and valgrind in our BlackHat class (http://blackhat.com/html/bh-usa-07/train-bh-us-07-mh.html). Mono maps some performance-critical .NET fucntionality to native C code, generally for doing crypto and protocol decoding. Have fun! :) PS: For bonus points see if a PC-Lint run will find some of the bugs ;> -- tangled strands of DNA explain the way that I behave. http://www.clock.org/~matt From dave at immunityinc.com Fri Jul 6 14:45:38 2007 From: dave at immunityinc.com (Dave Aitel) Date: Fri, 06 Jul 2007 14:45:38 -0400 Subject: [Dailydave] Heap Chunks and other wild creatures Message-ID: <468E8DD2.2080805@immunityinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This post isn't about the iPhone, but none-the-less I think it has pretty pictures involved. Here you can laugh at my "headshot": http://blogs.zdnet.com/security/?p=358 Here you can marvel at the magical heap tools in Immunity Debugger: http://www.immunityinc.com/downloads/Heap_Singapore_Jun_2007.pdf Here you can chortle at the remote Vista 0day and learn how to reorganize your business to handle 0day and learn how long 0day typically lasts: http://www.immunityinc.com/downloads/0day_IPO.pdf - -dave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGjo3QB8JNm+PA+iURAiZcAJ9x4n9eLtEQ3TRFHDVmPQtVdmSVFwCgjcGF grWjMoK8UUpCFxU9z23eHrs= =jEs3 -----END PGP SIGNATURE----- From nicob at nicob.net Sun Jul 8 18:14:11 2007 From: nicob at nicob.net (Nicob) Date: Mon, 09 Jul 2007 00:14:11 +0200 Subject: [Dailydave] SquirrelMail GPG Plugin vuln In-Reply-To: References: Message-ID: <1183932851.5978.140.camel@localhost> > Its probably not a good idea to give out so much information about > the vulnerabilities. The Squirrelmail GPG Plugin one says its a > command injection vulnerability. Shouldn't be too hard to rediscover > that. Version 2.1 of the SquirrelMail GPG Plugin was published yesterday. It blocks an attack vector I found after your mail while quickly grep'ing for dangerous PHP calls. I don't know if this patch killed the auctionned bug, but the funny comment in gpg_check_sign_pgp_mime() is still here. At least, my 2.0 PoC doesn't work anymore on 2.1 ;-)) Giving out some much information was really stupid ... Nicob From stefan.esser at sektioneins.de Mon Jul 9 03:26:56 2007 From: stefan.esser at sektioneins.de (Stefan Esser) Date: Mon, 09 Jul 2007 09:26:56 +0200 Subject: [Dailydave] SquirrelMail GPG Plugin vuln Message-ID: <4691E340.4060903@sektioneins.de> > Version 2.1 of the SquirrelMail GPG Plugin was published yesterday. It > blocks an attack vector I found after your mail while quickly grep'ing > for dangerous PHP calls. Version 2.1 of the plugin contains several more shell command execution vulnerabilities and the vendor is aware of this. And yes grepping for a few dangerous PHP calls is not that hard and you will sooner or later find these bugs. However to quote Halvar: "Auditing is not supergrep. " The real challenge with the SquirrelMail GPG Plugin vulnerabilties is not to find them after you got a hint that they exist. The challenge is to find out that (and how) you can launch them (at least some of them) PRE-AUTH. I really wonder if the auctionned bug is pre-auth or post-auth. I guess the later because otherwise they would have mentioned it. > Giving out some much information was really stupid ... Isn't that always the point when you sell a vulnerability in an open source software? If I want to sell you a lighttpd remote exploit and you trust me than you know that such a thing exists and you will most probably invest more time in finding it yourself. The knowledge that something exploitable really exists is a good motivation to find it. Stefan From cmiller at securityevaluators.com Mon Jul 9 09:46:29 2007 From: cmiller at securityevaluators.com (Charles Miller) Date: Mon, 9 Jul 2007 08:46:29 -0500 Subject: [Dailydave] SquirrelMail GPG Plugin vuln In-Reply-To: <4691E340.4060903@sektioneins.de> References: <4691E340.4060903@sektioneins.de> Message-ID: > > Isn't that always the point when you sell a vulnerability in an > open source > software? If I want to sell you a lighttpd remote exploit and you > trust me > than you know that such a thing exists and you will most probably > invest > more time in finding it yourself. The knowledge that something > exploitable > really exists is a good motivation to find it. The problem extends beyond open source. But anyway, there is a big difference between saying there is a remote exploit in IIS and saying there is a command injection vulnerability in SquirrelMail GPG Plugin. I can probably rediscover the SquirrelMail one in an hour but I may never find the IIS one. Also, the vulnerability Nicob pointed out was pre-auth (mine was post- auth). I'm dying to know if version 2.1 patched the exploit they are trying to sell! Charlie ps. Sorry about the (No Subject) From trklisted at networksamurai.org Mon Jul 9 16:23:12 2007 From: trklisted at networksamurai.org (mOses[at]networksamurai) Date: Mon, 09 Jul 2007 16:23:12 -0400 Subject: [Dailydave] Was Re: With great responsibility comes great power. In-Reply-To: References: Message-ID: <46929930.9080603@networksamurai.org> Well just thought I'd dig up this exiting topic with this link. Turns out Google maps (I guess this can't be found on the red friendly Google.cn....) has actually captures a satellite picture of a new class of Chinese submarine to replace its not so great submarine class. For several years its known that China has been ramping up its military, its also been discussed on this list recently that their are 'spies among us'. http://www.fas.org/blog/ssp/2007/07/new_chinese_ballistic_missile.php I wonder what else that google thing can pick up... M From nicob at nicob.net Mon Jul 9 17:32:22 2007 From: nicob at nicob.net (Nicob) Date: Mon, 09 Jul 2007 23:32:22 +0200 Subject: [Dailydave] SquirrelMail GPG Plugin vuln In-Reply-To: References: <4691E340.4060903@sektioneins.de> Message-ID: <1184016742.5902.19.camel@localhost> Le lundi 09 juillet 2007 ? 08:46 -0500, Charles Miller a ?crit : > Also, the vulnerability Nicob pointed out was pre-auth (mine was post- > auth). Simply sending an email to an user using the PGP plugin was enough to compromise the server hosting SquirrelMail. That's nice, as the webmail URL doesn't have to be known. The server can even be unreachable from the Internet. That's imho more than pre-auth, as you can blindly send tons of mails to random addresses and compromise some servers. 592 function gpg_check_sign_pgp_mime($message,$fullbodytext) { [...] 639 //$messageSignedText = escapeshellarg($messageSignedText); 640 $messageSignedText = ereg_replace("\"", "\\\"",$messageSignedText ); [...] 661 $command = "echo -n \"$messageSignedText\" | [blablabla] Nicob From nytrokiss at gmail.com Mon Jul 9 18:41:02 2007 From: nytrokiss at gmail.com (James Matthews) Date: Mon, 9 Jul 2007 15:41:02 -0700 Subject: [Dailydave] SquirrelMail GPG Plugin vuln In-Reply-To: <1184016742.5902.19.camel@localhost> References: <4691E340.4060903@sektioneins.de> <1184016742.5902.19.camel@localhost> Message-ID: <8a6b8e350707091541r28da265ap73be902571194221@mail.gmail.com> And now the person that wanted to make money is losing it because of you people being so nosy! Sniff Sniff =) On 7/9/07, Nicob wrote: > > Le lundi 09 juillet 2007 ? 08:46 -0500, Charles Miller a ?crit : > > Also, the vulnerability Nicob pointed out was pre-auth (mine was post- > > auth). > > Simply sending an email to an user using the PGP plugin was enough to > compromise the server hosting SquirrelMail. That's nice, as the webmail > URL doesn't have to be known. The server can even be unreachable from > the Internet. > > That's imho more than pre-auth, as you can blindly send tons of mails to > random addresses and compromise some servers. > > 592 function gpg_check_sign_pgp_mime($message,$fullbodytext) { > [...] > 639 //$messageSignedText = escapeshellarg($messageSignedText); > 640 $messageSignedText = ereg_replace("\"", "\\\"",$messageSignedText ); > [...] > 661 $command = "echo -n \"$messageSignedText\" | [blablabla] > > Nicob > > > > > > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave > -- http://www.goldwatches.com/watches.asp?Brand=14 http://www.jewelerslounge.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20070709/b4f2bdb0/attachment.htm From bbinger123 at yahoo.com Mon Jul 9 19:48:48 2007 From: bbinger123 at yahoo.com (bob jones) Date: Mon, 9 Jul 2007 16:48:48 -0700 (PDT) Subject: [Dailydave] SquirrelMail GPG Plugin vuln In-Reply-To: <8a6b8e350707091541r28da265ap73be902571194221@mail.gmail.com> Message-ID: <76774.77899.qm@web56012.mail.re3.yahoo.com> Who is going to spoil the yahoo IM bug? That would shake things up a bit more. James Matthews wrote: And now the person that wanted to make money is losing it because of you people being so nosy! Sniff Sniff =) On 7/9/07, Nicob < nicob at nicob.net> wrote:Le lundi 09 juillet 2007 ? 08:46 -0500, Charles Miller a ?crit : > Also, the vulnerability Nicob pointed out was pre-auth (mine was post- > auth). Simply sending an email to an user using the PGP plugin was enough to compromise the server hosting SquirrelMail. That's nice, as the webmail URL doesn't have to be known. The server can even be unreachable from the Internet. That's imho more than pre-auth, as you can blindly send tons of mails to random addresses and compromise some servers. 592 function gpg_check_sign_pgp_mime($message,$fullbodytext) { [...] 639 //$messageSignedText = escapeshellarg($messageSignedText); 640 $messageSignedText = ereg_replace("\"", "\\\"",$messageSignedText ); [...] 661 $command = "echo -n \"$messageSignedText\" | [blablabla] Nicob _______________________________________________ Dailydave mailing list Dailydave at lists.immunitysec.com http://lists.immunitysec.com/mailman/listinfo/dailydave -- http://www.goldwatches.com/watches.asp?Brand=14 http://www.jewelerslounge.com _______________________________________________ Dailydave mailing list Dailydave at lists.immunitysec.com http://lists.immunitysec.com/mailman/listinfo/dailydave --------------------------------- Be a better Globetrotter. Get better travel answers from someone who knows. Yahoo! Answers - Check it out. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20070709/83a8cbd3/attachment.htm From lists at bughunter.ca Tue Jul 10 16:21:42 2007 From: lists at bughunter.ca (J.M. Seitz) Date: Tue, 10 Jul 2007 13:21:42 -0700 Subject: [Dailydave] PyFault 0.1a Message-ID: <006201c7c32f$ee983460$6207a8c0@jseitz> Hey All, I have begun writing a little class to do some fault injection on Win32 applications. Currently it only has DLL injection/ejection which is useful if you are a MS Detours kinda person, or are writing DLL payloads for exploits and you want a quick and dirty way of getting them in and out of processes. Really I am looking for comments, and suggestsion on some interesting fault cases that everyone would like to see. As time permits I will be expanding this library to pound the snot out of software in all kinds of interesting ways. You can download it here: http://vdalabs.com/tools/pyfault.html And I look forward to your comments, suggestions and bug fix requests. JS jms at bughunter.ca -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20070710/a470efd3/attachment.htm From lmh at info-pull.com Wed Jul 11 01:17:48 2007 From: lmh at info-pull.com (Lance M. Havok) Date: Tue, 10 Jul 2007 22:17:48 -0700 Subject: [Dailydave] Considerations for a "secure" embedded system Message-ID: After reading and playing in the past with gems like Gentoo Embedded and Gentoo Hardened, I wonder about the current possibilities *today* for developing a portable system deploying grsecurity, PaX and friends (even SELinux since they fixed some memory footprint issues time ago, but probably still have issues with busybox and shrinking the policy to a simplified variant). Let's think about x86 first, then ARM. What options are available right now and how feasible is to use them? The requirements of buildroot for building the customized system, or the usage of Gentoo Embedded. With all the buzz on virtualization technologies, 'virtual appliances', etc, the point behind installing Unbungu Muslim/Christian Server Edition seems to be moot. There's no sense behind virtualization if you run your imapd on the same machine as the LDAP monster and get one of them compromised right away. No mention to the default configuration of vmware-server's authd, and requirement of xinetd. If you can run a uclibc-based system with a few security enhancements, and take less than 100MB for the whole thing including your target service, using a full-fledged 'distribution' does not make any sense. The next question would be: How easy is to update the system images? How about batch building them, including services dynamically from a profile. vmware-server supports scripting even. How complex is the build process itself. Can the toolchain be shared across builds for the same platform, and does the 'framework' support that? How about things like JFFS not supporting (yet) filesystem extended attributes? Just a few dumb thoughts. PS: Again, let's base this on a x86 compatible platform. It might sound cool for a geeky audience to run spender's backdoor on a ARM5 fridge and let him steal your tacos, but such a thing is not really useful except for wasting time. From andre at operations.net Thu Jul 12 00:07:11 2007 From: andre at operations.net (Andre Gironda) Date: Wed, 11 Jul 2007 23:07:11 -0500 Subject: [Dailydave] Considerations for a "secure" embedded system In-Reply-To: References: Message-ID: <2fd9390e0707112107s3b95d325g13d342131c63e7fd@mail.gmail.com> Only ARM v6 supports XN. Programmers don't like using it though because they can spend their memory on more important things. Memory is expensive for embedded devices still. Basically, you could get it to work but then you couldn't get it to run anything interesting. Are there any other good grsecurity distro's besides Gentoo Hardened? Devil-linux and the others listed on distrowatch are lacking, but might be interesting for your project. dre On 7/11/07, Lance M. Havok wrote: > > After reading and playing in the past with gems like Gentoo Embedded > and Gentoo Hardened, I wonder about the current possibilities *today* > for developing a portable system deploying grsecurity, PaX and friends > (even SELinux since they fixed some memory footprint issues time ago, > but probably still have issues with busybox and shrinking the policy > to a simplified variant). > > Let's think about x86 first, then ARM. What options are available > right now and how feasible is to use them? > > The requirements of buildroot for building the customized system, or > the usage of Gentoo Embedded. With all the buzz on virtualization > technologies, 'virtual appliances', etc, the point behind installing > Unbungu Muslim/Christian Server Edition seems to be moot. There's no > sense behind virtualization if you run your imapd on the same machine > as the LDAP monster and get one of them compromised right away. No > mention to the default configuration of vmware-server's authd, and > requirement of xinetd. > > If you can run a uclibc-based system with a few security enhancements, > and take less than 100MB for the whole thing including your target > service, using a full-fledged 'distribution' does not make any sense. > > The next question would be: How easy is to update the system images? > How about batch building them, including services dynamically from a > profile. vmware-server supports scripting even. How complex is the > build process itself. Can the toolchain be shared across builds for > the same platform, and does the 'framework' support that? How about > things like JFFS not supporting (yet) filesystem extended attributes? > > Just a few dumb thoughts. > PS: Again, let's base this on a x86 compatible platform. It might > sound cool for a geeky audience to run spender's backdoor on a ARM5 > fridge and let him steal your tacos, but such a thing is not really > useful except for wasting time. > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20070711/f96a285d/attachment-0001.htm From dave at immunityinc.com Fri Jul 13 17:08:27 2007 From: dave at immunityinc.com (Dave Aitel) Date: Fri, 13 Jul 2007 17:08:27 -0400 Subject: [Dailydave] Parties, Immunity Debugger Beta and a blast from the past Message-ID: <4697E9CB.6000407@immunityinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 http://archives.neohapsis.com/archives/fulldisclosure/2003-q4/3777.html Today's blast from the past is a Squirrelmail GPG-plugin advisory from 2003 that I found while looking for exploits for modern versions. Back in the day you just made fun of such things, whereas now you sell them to people, it looks like. In other news Immunity is co-hosting with Applied Security an exclusive party at the Bellagio in Vegas on August 3rd. Among other reasons, we'd like to celebrate the launch of Immunity Debugger with free drinks! Immunity Debugger, if you haven't read the talk Nico gave at SyScan [1], is a vulnerability focused debugger with a nice GUI and a Python API built-in. We think it's great and the beta testers have loved it so far! Damian Gomez, the primary developer, is going to be giving a Defcon talk on it that you should be sure to catch. We do have (limited) room for a few more beta testers. If you are not on the Immunity Debugger beta list, but think you should be, just send betaid at immunityinc.com a quick paragraph as to why. A select group of our beta testers will receive invites to the party (send your snail-mail address with your Beta request). We're especially looking for experienced exploit writers and reverse engineers who are interested in using the Immunity Debugger Python API. - -dave [1] http://www.immunityinc.com/downloads/Heap_Singapore_Jun_2007.pdf -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGl+m7B8JNm+PA+iURAjzPAJ9c5/Pk7eh2l2zIADni6z79dXHzOwCfSiCn wP3txbXz5SF90MWFcHNXvX8= =oHMz -----END PGP SIGNATURE----- From dave at immunityinc.com Mon Jul 16 12:32:17 2007 From: dave at immunityinc.com (Dave Aitel) Date: Mon, 16 Jul 2007 12:32:17 -0400 Subject: [Dailydave] An os x worm, oh noes! Message-ID: <469B9D91.3080005@immunityinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I note that "Infosecurity Sellout" is claiming there is another bug in mDNS which is wormable.[1] This is obviously untrue, since there are no more remote bugs in OS X. For the record, I did not discover any bugs in mDNS previously. For the past few days I've been writing an x86 assembler - I'm usually doing such things. When I'm not doing consulting work, I work on the guts of CANVAS. This leaves very little time for exploit writing. Writing an x86 assembler can be fun though. There really aren't very many good papers on how to do this sort of thing from a practical perspective so when I'm done, I'll write it up. - -dave http://infosecsellout.blogspot.com/2007/07/oh-look-apple-worm.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGm52QB8JNm+PA+iURAteoAJ9MuJfewZyemWN9ojujYmdfeDoZ6QCeKguw ZMvSX+HkVKafwqk9zIUoO1s= =ADYC -----END PGP SIGNATURE----- From bbinger123 at yahoo.com Mon Jul 16 19:22:01 2007 From: bbinger123 at yahoo.com (Bee Binger) Date: Mon, 16 Jul 2007 16:22:01 -0700 (PDT) Subject: [Dailydave] An os x worm, oh noes! In-Reply-To: <469B9D91.3080005@immunityinc.com> Message-ID: <134.84915.qm@web56011.mail.re3.yahoo.com> Interesting on the assembler writing. I was curious on a few points about it Which syntax is it going to support? Is it going to have many high level helpers like masm or be more bare bones? Probably most important ... which types of object files will it be able to produce? Is it going to be a quick learning experince or is it being designed more modular so other people can extend it? My only suggestion would to be keep it nasm style and make the coder specify sizes on compares, moves, "lea"s and other operations where the size of the operation can be ambigious. It makes the coder have to cocentrate more. Dave Aitel wrote: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I note that "Infosecurity Sellout" is claiming there is another bug in mDNS which is wormable.[1] This is obviously untrue, since there are no more remote bugs in OS X. For the record, I did not discover any bugs in mDNS previously. For the past few days I've been writing an x86 assembler - I'm usually doing such things. When I'm not doing consulting work, I work on the guts of CANVAS. This leaves very little time for exploit writing. Writing an x86 assembler can be fun though. There really aren't very many good papers on how to do this sort of thing from a practical perspective so when I'm done, I'll write it up. - -dave http://infosecsellout.blogspot.com/2007/07/oh-look-apple-worm.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGm52QB8JNm+PA+iURAteoAJ9MuJfewZyemWN9ojujYmdfeDoZ6QCeKguw ZMvSX+HkVKafwqk9zIUoO1s= =ADYC -----END PGP SIGNATURE----- _______________________________________________ Dailydave mailing list Dailydave at lists.immunitysec.com http://lists.immunitysec.com/mailman/listinfo/dailydave --------------------------------- Sucker-punch spam with award-winning protection. Try the free Yahoo! Mail Beta. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20070716/f0e12a8c/attachment.htm From nruff at security-labs.org Tue Jul 17 05:07:39 2007 From: nruff at security-labs.org (Nicolas RUFF) Date: Tue, 17 Jul 2007 11:07:39 +0200 Subject: [Dailydave] SquirrelMail GPG Plugin vuln In-Reply-To: <76774.77899.qm@web56012.mail.re3.yahoo.com> References: <76774.77899.qm@web56012.mail.re3.yahoo.com> Message-ID: <469C86DB.801@security-labs.org> > Who is going to spoil the yahoo IM bug? That would shake things up a bit > more. It might be related to: http://www.xdisclose.com/advisory/XD100002.html This bug requires "deep" user interaction ... you have to be in the target's address book! Regards, - Nicolas RUFF From shrdlu at deaddrop.org Tue Jul 17 11:02:04 2007 From: shrdlu at deaddrop.org (Lynda (aka Etaoin Shrdlu)) Date: Tue, 17 Jul 2007 08:02:04 -0700 Subject: [Dailydave] MOSDEF Mailing List Archives Message-ID: <469CD9EC.10501@deaddrop.org> I have wondered for some time about the fate of the mosdef mailing list. The link is still there on the immunitysec page, but there's only an error waiting on the other side. Even if the list itself is dead, would it be possible to resurrect the archives? There was a lot of useful information in there, and I miss being able to access it. I wasn't subscribed (my mistake), and I'd really be appreciative of seeing them back online, in some form or other. -- Entrepreneurs are simply those who understand that there is little difference between obstacle and opportunity and are able to turn both to their advantage. Niccolo Machiavelli From dave at immunityinc.com Tue Jul 17 16:20:22 2007 From: dave at immunityinc.com (Dave Aitel) Date: Tue, 17 Jul 2007 16:20:22 -0400 Subject: [Dailydave] add %ebx, (%esi) Message-ID: <469D2486.4080308@immunityinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 There are a lot of different ways to assemble things on x86. For example, add %ebx, (%esi) can be done in either two bytes, or three. This is mostly important to you if you're writing shellcode and need to avoid bad bytes or optimize for space or just avoid IDS sigs. But without controlling the guts of your assembler, it's hard to do this automatically. MOSDEF has always had an x86 assembler, but it was slow (based on spark.py as a parser, which was the best available at the time MOSDEF was created originally). I've rewritten the x86 assembler's parser and you can now access a small web sample here: http://www.immunityinc.com/cgi-bin/assemble.py . You may or may not find this useful. Let me know if you find any bugs! I'm not sure where the old MOSDEF mailing list archives are, but we'll take a look at the backups and see if we can find them. Also new on the website today is this: http://www.immunityinc.com/resources-dkm.shtml - -dave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGnSSDB8JNm+PA+iURAg94AKDgV8q6oKjPz5ZN2SsQCVpOwmPqoQCfcZZA ny9EthRXynG136V2f1wF0pI= =J910 -----END PGP SIGNATURE----- From bbinger123 at yahoo.com Tue Jul 17 17:46:40 2007 From: bbinger123 at yahoo.com (Bee Binger) Date: Tue, 17 Jul 2007 14:46:40 -0700 (PDT) Subject: [Dailydave] add %ebx, (%esi) In-Reply-To: <469D2486.4080308@immunityinc.com> Message-ID: <944206.14902.qm@web56001.mail.re3.yahoo.com> I was messing around with your assembler.py and found a couple points of interest. When using the 'bt' instruction the assembler throws the "error ..(sorry)" message. I was sending part of my sys_select code into the app and my fd_isset uses the bt instruction to check if a fd is set and it seems the script did not know this instruction. ( not a bug but would make me have to rewrite a bit of my socket apps ) Also it seems to throw that same error on many "rep" operations ( I couldnt find a valid combination of registers/rep instructions without getting the error thrown ) This last part was more my curiosity than anything but it is making me wonder alot.. for the default xor %eax,%eax in the textbox I was expecting to see 31 and c0 for the opcodes but I saw 0x33 and 0xc0. I looked at the intel manuals and it said: 31 / r XOR r/m32,r32 r/m32 XOR r32 33 / r XOR r32,r/m32 r8 XOR r/m8 There was also similar results with the add, sub, and other math instructions in your script always using the r32 choice as the left operand instead of the r/m32. Is this some optimization trick? If both are registers then they would use the same amount of clock cycles, but it seems to be limited only register manipulation and not addresses. I couldnt figure out how in the text box to declare sections because I was wondering if 31 would be produced for xor if a variable from the.data section was the source operand since it seems 33 would break on this or not be allowed. Anyway seems pretty cool nice job >>Dave Aitel wrote:>. I've rewritten the x86 assembler's parser and >you can now access a small web sample here: >http://www.immunityinc.com/cgi-bin/assemble.py . You may or may >not find this useful. Let me know if you find any bugs! --------------------------------- Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20070717/89b3b12f/attachment.htm From mateuszb at gmail.com Tue Jul 17 19:19:54 2007 From: mateuszb at gmail.com (Mateusz Berezecki) Date: Wed, 18 Jul 2007 01:19:54 +0200 Subject: [Dailydave] add %ebx, (%esi) In-Reply-To: <469D2486.4080308@immunityinc.com> References: <469D2486.4080308@immunityinc.com> Message-ID: On 7/17/07, Dave Aitel wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > MOSDEF has always had an x86 assembler, but it was slow (based on > spark.py as a parser, which was the best available at the time MOSDEF > was created originally). I've rewritten the x86 assembler's parser and > you can now access a small web sample here: > http://www.immunityinc.com/cgi-bin/assemble.py . You may or may not > find this useful. Let me know if you find any bugs! You should try ANTLR parser generator. It supports outputing automatically generated parsers/interpreters/translators/etc in C#, Objective-C, C, C++, Java , Ruby and Python. So whatever is needed is there. It is a LL(*) parser generator unlike most of old flex/bison which are LR ones. It's worth mentioning since version 3 is already out there :) Mateusz Berezecki From dave at immunityinc.com Thu Jul 19 14:12:29 2007 From: dave at immunityinc.com (Dave Aitel) Date: Thu, 19 Jul 2007 14:12:29 -0400 Subject: [Dailydave] add %ebx, (%esi) In-Reply-To: <944206.14902.qm@web56001.mail.re3.yahoo.com> References: <944206.14902.qm@web56001.mail.re3.yahoo.com> Message-ID: <469FA98D.3040008@immunityinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bee Binger wrote: > I was messing around with your assembler.py and found a couple > points of interest. > > When using the 'bt' instruction the assembler throws the "error > ..(sorry)" message. I was sending part of my sys_select code into > the app and my fd_isset uses the bt instruction to check if a fd is > set and it seems the script did not know this instruction. ( not a > bug but would make me have to rewrite a bit of my socket apps ) > > Also it seems to throw that same error on many "rep" operations ( I > couldnt find a valid combination of registers/rep instructions > without getting the error thrown ) > "rep movsb" works for me. I'm not sure we support this very well though. Piotr noticed we don't do 16 bit addressing very well at all. Which so far hasn't hurt us, since our shellcode doesn't use it. This is very much a shellcode/proglet assembler. I added bt this morning, so that should work nicely for you now. For bonus credit I added bswap. :> Also Skylined pointed out there are three add %ebx, (%esi) possibilities, not two. > This last part was more my curiosity than anything but it is making > me wonder alot.. > > for the default xor %eax,%eax in the textbox I was expecting to see > 31 and c0 for the opcodes but I saw 0x33 and 0xc0. I looked at > the intel manuals and it said: > > 31 / r XOR r/m32,r32 r/m32 XOR r32 33 / r XOR r32,r/m32 > r8 XOR r/m8 > > There was also similar results with the add, sub, and other math > instructions in your script always using the r32 choice as the left > operand instead of the r/m32. Is this some optimization trick? If > both are registers then they would use the same amount of clock > cycles, but it seems to be limited only register manipulation and > not addresses. I couldnt figure out how in the text box to declare > sections because I was wondering if 31 would be produced for xor > if a variable from the.data section was the source operand since it > seems 33 would break on this or not be allowed. > You can't really define sections for this assembler - but we haven't had any problems. Let me know if there's something wacky here about the x86 arch I didn't understand properly. We have been using a similar (though much slower) assembler for a few years now in all of our exploits (which is why I can finish an assembler in a week, rather than a month or two). Once the C parser is rewritten, I'll release it all as LGPL and you can fix it :>. I really like the idea of a web service for shellcode decoder creation. This was part of the original idea for the CANVAS World Service (which we're still going to do some day). One of the major advantages is that people who invest lots of time for their own customized polymorphic decoders could offer them as a web service attached to CANVAS World Service and then charge a buck every time they are used, for example. And having them as a web service also means IDS companies can't easily write signatures, since you can change them every day and they never see the code that generates the shellcode decoder itself. For now, having an assembler web service is pretty fun. :> - -dave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGn6mLB8JNm+PA+iURApXtAJsEXfRAedswtwHYk+AJ7D7WPmjF5ACeJnYZ 5FEJBd+5ubFCJCXSYQOkReE= =RiFT -----END PGP SIGNATURE----- From bjwever at microsoft.com Fri Jul 20 08:36:32 2007 From: bjwever at microsoft.com (Berend-Jan Wever (SKYLINED)) Date: Fri, 20 Jul 2007 13:36:32 +0100 Subject: [Dailydave] add %ebx, (%esi) In-Reply-To: <469FA98D.3040008@immunityinc.com> References: <944206.14902.qm@web56001.mail.re3.yahoo.com> <469FA98D.3040008@immunityinc.com> Message-ID: Hi all, I got a few questions about the three instructions, so here you go: 011E ADD DWORD PTR DS:[ESI],EBX 015E 00 ADD DWORD PTR DS:[ESI],EBX 019E 00000000 ADD DWORD PTR DS:[ESI],EBX What you're really coding is: 015E 00 ADD DWORD PTR DS:[ESI+0x00],EBX 019E 00000000 ADD DWORD PTR DS:[ESI+0x00000000],EBX But why limit yourself to one instruction to get the job done? 8706 XCHG DWORD PTR DS:[ESI],EAX 8D0418 LEA EAX,DWORD PTR DS:[EAX+EBX] 8706 XCHG DWORD PTR DS:[ESI],EAX The above code does exactly the same with entirely different bytes. You can create more variations using other registers than EAX and/or add the 0 BYTE or DWORD offset as with the first two variations. Here's another way of doing it: 031E ADD EBX,DWORD PTR DS:[ESI] 871E XCHG DWORD PTR DS:[ESI],EBX 2B1E SUB EBX,DWORD PTR DS:[ESI] F7DB NEG EBX The number of variations of achieving the same thing is actually very large. It would be nice to be able to determine how many variations there are in total. I'm only interested in variations that don't use "nop" instructions that don't do anything useful. There must be a way to do it and prove that you've got all of them. You can also use knowledge of the (static) contents of registers and memory for even more variations: If EAX = 0: 011C30 ADD DWORD PTR DS:[EAX+ESI],EBX 011C46 ADD DWORD PTR DS:[ESI+EAX*2],EBX 011C86 ADD DWORD PTR DS:[ESI+EAX*4],EBX If EAX = 0xDEADBEEF: 019C30 11415221 ADD DWORD PTR DS:[EAX+ESI+0x21524111],EBX Finally, if you know a register or memory location does not hold a value you need to save, you can use that register or memory to create even more variations: Using stack: FF36 PUSH DWORD PTR DS:[ESI] 3E:011C24 ADD DWORD PTR DS:[ESP],EBX 8F06 POP DWORD PTR DS:[ESI] If you want to generate this kind of assembler automatically, you will need a very abstract programming language that allow you to describe WHAT you want to achieve instead of HOW you want to do it. The more abstract you can be in your description, the more room you leave to the compiler to choose and order the instructions that do what you want. If you were to implement this, you should be able to generate output code that adheres to the strictest limitations on the available characters in the instructions. You will of course need a few instructions that allow you to do something, eg. you'll never get anything done using only the NOP instruction. I'd be interested to know what the smallest set of characters is that one can possibly code a working program in. I'd also be very interested in comparing code generated by such a compiler to code I created manually for, for instance, ALPHA2's alphanumeric shellcode decoders and see where it can be improved. Cheers, SkyLined Berend-Jan "SkyLined" Wever | Security Software Engineer | SWI-UK | mobile: +44 7790 755 813 | email: mailto:SkyLined at microsoft.com -----Original Message----- From: dailydave-bounces at lists.immunitysec.com [mailto:dailydave-bounces at lists.immunitysec.com] On Behalf Of Dave Aitel Sent: Thursday 19 July 2007 19:12 To: dailydave at lists.immunitysec.com Subject: Re: [Dailydave] add %ebx, (%esi) -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bee Binger wrote: > I was messing around with your assembler.py and found a couple > points of interest. > > When using the 'bt' instruction the assembler throws the "error > ..(sorry)" message. I was sending part of my sys_select code into > the app and my fd_isset uses the bt instruction to check if a fd is > set and it seems the script did not know this instruction. ( not a > bug but would make me have to rewrite a bit of my socket apps ) > > Also it seems to throw that same error on many "rep" operations ( I > couldnt find a valid combination of registers/rep instructions > without getting the error thrown ) > "rep movsb" works for me. I'm not sure we support this very well though. Piotr noticed we don't do 16 bit addressing very well at all. Which so far hasn't hurt us, since our shellcode doesn't use it. This is very much a shellcode/proglet assembler. I added bt this morning, so that should work nicely for you now. For bonus credit I added bswap. :> Also Skylined pointed out there are three add %ebx, (%esi) possibilities, not two. > This last part was more my curiosity than anything but it is making > me wonder alot.. > > for the default xor %eax,%eax in the textbox I was expecting to see > 31 and c0 for the opcodes but I saw 0x33 and 0xc0. I looked at > the intel manuals and it said: > > 31 / r XOR r/m32,r32 r/m32 XOR r32 33 / r XOR r32,r/m32 > r8 XOR r/m8 > > There was also similar results with the add, sub, and other math > instructions in your script always using the r32 choice as the left > operand instead of the r/m32. Is this some optimization trick? If > both are registers then they would use the same amount of clock > cycles, but it seems to be limited only register manipulation and > not addresses. I couldnt figure out how in the text box to declare > sections because I was wondering if 31 would be produced for xor > if a variable from the.data section was the source operand since it > seems 33 would break on this or not be allowed. > You can't really define sections for this assembler - but we haven't had any problems. Let me know if there's something wacky here about the x86 arch I didn't understand properly. We have been using a similar (though much slower) assembler for a few years now in all of our exploits (which is why I can finish an assembler in a week, rather than a month or two). Once the C parser is rewritten, I'll release it all as LGPL and you can fix it :>. I really like the idea of a web service for shellcode decoder creation. This was part of the original idea for the CANVAS World Service (which we're still going to do some day). One of the major advantages is that people who invest lots of time for their own customized polymorphic decoders could offer them as a web service attached to CANVAS World Service and then charge a buck every time they are used, for example. And having them as a web service also means IDS companies can't easily write signatures, since you can change them every day and they never see the code that generates the shellcode decoder itself. For now, having an assembler web service is pretty fun. :> - -dave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGn6mLB8JNm+PA+iURApXtAJsEXfRAedswtwHYk+AJ7D7WPmjF5ACeJnYZ 5FEJBd+5ubFCJCXSYQOkReE= =RiFT -----END PGP SIGNATURE----- _______________________________________________ Dailydave mailing list Dailydave at lists.immunitysec.com http://lists.immunitysec.com/mailman/listinfo/dailydave From bbinger123 at yahoo.com Fri Jul 20 11:21:31 2007 From: bbinger123 at yahoo.com (Bee Binger) Date: Fri, 20 Jul 2007 08:21:31 -0700 (PDT) Subject: [Dailydave] add %ebx, (%esi) In-Reply-To: Message-ID: <12741.51159.qm@web56013.mail.re3.yahoo.com> Interesting replies... I also didnt realize this was for mostly generating "shellcode", but with a little thought I could of probably figured this out. "Berend-Jan Wever (SKYLINED)" wrote: >>The number of variations of achieving the same thing is actually very >>large. It would be nice to be able to determine how many variations >>there are in total. I'm only interested in variations that don't use "nop" >>instructions that don't do anything useful. There must be a way to do >>it and prove that you've got all of them. >>Cheers, >>SkyLined Do you actually think its possible to find *every* combination? I have thought about it a bit since reading your email and if there are no size/performance/opcode restrictions then I think you could have an unlimited amount of combinations ( assuming we are using your last example about extending one instruction into multiple). It would somewhat depend on what exactly you consider a nop instruction too. Also if you move away from the basic instruction set into the "extended ones" ( i do not know the real name for all the multimedia and floating point ones), then you would have extreme problems trying to match them all. Dave Aitel wrote: >>Which so far hasn't hurt us, since our shellcode doesn't use it. This >>is very much a shellcode/proglet assembler. I should have realized this point before, but it went right past me. >> I added bt this morning, so that should work nicely for you now. For bonus >>credit I added bswap. :>. gracias >> We have been using a similar (though much slower) assembler for a few >> years now in all of our exploits (which is why I can finish an assembler in a >> week, rather than a month or two). I was wondering this exact thing >> Once the C parser is rewritten, I'll release it all as LGPL and you can fix it :>. /me hides >> I really like the idea of a web service for shellcode decoder creation. This was >> part of the original idea for the CANVAS World Service (which we're still going >> to do some day). this would be amazing, especially if some of skylined ideas ( multiple instructions, setting fixed offsets to introduce alot of math instructions to break patterns) would be incorporated. >> - -dave --------------------------------- Pinpoint customers who are looking for what you sell. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20070720/054083c9/attachment.htm From bbinger123 at yahoo.com Fri Jul 20 11:26:30 2007 From: bbinger123 at yahoo.com (Bee Binger) Date: Fri, 20 Jul 2007 08:26:30 -0700 (PDT) Subject: [Dailydave] add %ebx, (%esi) In-Reply-To: <46A08E5F.8090202@orange-ftgroup.com> Message-ID: <517064.53810.qm@web56013.mail.re3.yahoo.com> Very nice! My only complaint is that it is written in Ruby instead of a more readable language to me -- like perl ;) TINNES Julien RD-MAPS-ISS wrote: Hello, a quick advertisement: you may be interested by http://metasm.cr0.org a Cheers, --------------------------------- Shape Yahoo! in your own image. Join our Network Research Panel today! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20070720/6b7ddd3f/attachment.htm From mateuszb at gmail.com Fri Jul 20 14:33:02 2007 From: mateuszb at gmail.com (Mateusz Berezecki) Date: Fri, 20 Jul 2007 20:33:02 +0200 Subject: [Dailydave] add %ebx, (%esi) In-Reply-To: <12741.51159.qm@web56013.mail.re3.yahoo.com> References: <12741.51159.qm@web56013.mail.re3.yahoo.com> Message-ID: On 7/20/07, Bee Binger wrote: > > Do you actually think its possible to find *every* combination? Think Prolog. If my memory serves me right (I haven't been doing prolog for more than 2 years) you could do just that with prolog programming language and something called constraint programming. But I'm no oracle here. Mateusz Berezecki From jt at cr0.org Fri Jul 20 17:11:50 2007 From: jt at cr0.org (Julien TINNES) Date: Fri, 20 Jul 2007 23:11:50 +0200 Subject: [Dailydave] Announcing metasm Message-ID: <20070720211150.GB3418@cr0.org> We decided to release the first beta version (0.1) of metasm, an advanced assembly manipulation suite written in Ruby under the LGPL licence. Metasm features a cross architecture and cross platform assembler, disassembler and linker. It also has some advanced features such as remote process manipulation, a GCC-compatible preprocessor and automatic backtracking in the disassembler. We encourage you to take a look at the "samples" directory to discover some of the advanced usages of this tool. It is still under heavy development by Yoann Guillot and you can expect more features and more architectures to be supported soon. You can download everything at http://metasm.cr0.org, including the stable mercurial repository or download it directly at http://metasm.cr0.org/downloads/metasm-0.1.tgz We hope you'll enjoy it! -- Julien TINNES http://www.cr0.org From tqbf at matasano.com Sat Jul 21 19:22:31 2007 From: tqbf at matasano.com (Thomas Ptacek) Date: Sat, 21 Jul 2007 18:22:31 -0500 Subject: [Dailydave] Announcing metasm In-Reply-To: <20070720211150.GB3418@cr0.org> References: <20070720211150.GB3418@cr0.org> Message-ID: <1df0a410707211622m6a2c38fam7bf75593013d189e@mail.gmail.com> We've had a lot of luck with a very similar approach. Ours is in Python, only supports x86, and isn't as complete; it also tries less hard to look like a DSL. But we like it. If anyone's interested, we'd be happy to post. On 7/20/07, Julien TINNES wrote: > We decided to release the first beta version (0.1) of metasm, an advanced > assembly manipulation suite written in Ruby under the LGPL licence. > > Metasm features a cross architecture and cross platform assembler, > disassembler and linker. > It also has some advanced features such as remote process manipulation, a > GCC-compatible preprocessor and automatic backtracking in the disassembler. > > We encourage you to take a look at the "samples" directory to discover some of > the advanced usages of this tool. > > It is still under heavy development by Yoann Guillot and you can expect more > features and more architectures to be supported soon. > > You can download everything at http://metasm.cr0.org, including the stable > mercurial repository or download it directly at > http://metasm.cr0.org/downloads/metasm-0.1.tgz > > We hope you'll enjoy it! > > -- > Julien TINNES > http://www.cr0.org > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave > -- --- Thomas H. Ptacek // matasano security read us on the web: http://www.matasano.com/log From dave at immunityinc.com Sun Jul 22 11:14:21 2007 From: dave at immunityinc.com (Dave Aitel) Date: Sun, 22 Jul 2007 11:14:21 -0400 Subject: [Dailydave] Announcing metasm In-Reply-To: <1df0a410707211622m6a2c38fam7bf75593013d189e@mail.gmail.com> References: <20070720211150.GB3418@cr0.org> <1df0a410707211622m6a2c38fam7bf75593013d189e@mail.gmail.com> Message-ID: <46A3744D.4020009@immunityinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thomas Ptacek wrote: > We've had a lot of luck with a very similar approach. Ours is in > Python, only supports x86, and isn't as complete; it also tries > less hard to look like a DSL. But we like it. If anyone's > interested, we'd be happy to post. How do these things differ from MOSDEF (other than having a disassembler?) Is the goal here an injectable proglet session or just a nice way to assembler/disassemble shellcode? - -dave > > On 7/20/07, Julien TINNES wrote: >> We decided to release the first beta version (0.1) of metasm, an >> advanced assembly manipulation suite written in Ruby under the >> LGPL licence. >> >> Metasm features a cross architecture and cross platform >> assembler, disassembler and linker. It also has some advanced >> features such as remote process manipulation, a GCC-compatible >> preprocessor and automatic backtracking in the disassembler. >> >> We encourage you to take a look at the "samples" directory to >> discover some of the advanced usages of this tool. >> >> It is still under heavy development by Yoann Guillot and you can >> expect more features and more architectures to be supported soon. >> >> >> You can download everything at http://metasm.cr0.org, including >> the stable mercurial repository or download it directly at >> http://metasm.cr0.org/downloads/metasm-0.1.tgz >> >> We hope you'll enjoy it! >> >> -- Julien TINNES http://www.cr0.org >> _______________________________________________ Dailydave mailing >> list Dailydave at lists.immunitysec.com >> http://lists.immunitysec.com/mailman/listinfo/dailydave >> > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGo3RLB8JNm+PA+iURAhfgAJ9olcz0LenjFmbJUfsYB+28+eSHiwCguM9R F6zjLoEm1+Vyp/CND2V1F58= =Fo++ -----END PGP SIGNATURE----- From tqbf at matasano.com Sun Jul 22 12:41:58 2007 From: tqbf at matasano.com (Thomas Ptacek) Date: Sun, 22 Jul 2007 11:41:58 -0500 Subject: [Dailydave] Announcing metasm In-Reply-To: <46A3744D.4020009@immunityinc.com> References: <20070720211150.GB3418@cr0.org> <1df0a410707211622m6a2c38fam7bf75593013d189e@mail.gmail.com> <46A3744D.4020009@immunityinc.com> Message-ID: <1df0a410707220941y27a0543ak35fdb05abd672034@mail.gmail.com> I've learned not to benchmark ideas against MOSDEF; it's dispiriting. The difference between my code and yours, apart from maturity and originality, is that yours focuses on assembly language and mine focuses on a class hierarchy for opcodes. I wanted to see how far I could get using Python as a superficial IL for x86. My goal isn't shellcode; it's process[or] manipulation. I used it to write a debugger to run over firewire. > Thomas Ptacek wrote: > > We've had a lot of luck with a very similar approach. Ours is in > > Python, only supports x86, and isn't as complete; it also tries > > less hard to look like a DSL. But we like it. If anyone's > > interested, we'd be happy to post. > How do these things differ from MOSDEF (other than having a disassembler?) -- --- Thomas H. Ptacek // matasano security read us on the web: http://www.matasano.com/log From dave.aitel at gmail.com Mon Jul 23 08:07:50 2007 From: dave.aitel at gmail.com (Dave Aitel) Date: Mon, 23 Jul 2007 08:07:50 -0400 Subject: [Dailydave] Announcing metasm In-Reply-To: <1df0a410707220941y27a0543ak35fdb05abd672034@mail.gmail.com> References: <20070720211150.GB3418@cr0.org> <1df0a410707211622m6a2c38fam7bf75593013d189e@mail.gmail.com> <46A3744D.4020009@immunityinc.com> <1df0a410707220941y27a0543ak35fdb05abd672034@mail.gmail.com> Message-ID: Is this debugger something you'd want integrated with Immunity Debugger? When you say "debugger that runs over firewire" do you mean kinda like WinDBG does when you're trying to do kernel debugging? I'm writing a kernel exploit all day today, but no chance of setting up WinDBG to do it - it's almost easier just to use memory dumps and !analyze -v. The WinDBG UI is almost as bad as SPIKE Proxy's. One thing MOSDEF is not good at is enumerating all the different ways to add two numbers together. We only put one kind of encoding into the assembler and changing it now would be quite difficult. But we're optimized for shellcode size, and speed, while remaining pure-Python. Which is annoying because those are all polar opposites. What dialect of assembler is it that metasm implements? Is that NASM-like? -dave On 7/22/07, Thomas Ptacek wrote: > > I've learned not to benchmark ideas against MOSDEF; it's dispiriting. > > The difference between my code and yours, apart from maturity and > originality, is that yours focuses on assembly language and mine > focuses on a class hierarchy for opcodes. I wanted to see how far I > could get using Python as a superficial IL for x86. > > My goal isn't shellcode; it's process[or] manipulation. I used it to > write a debugger to run over firewire. > > > Thomas Ptacek wrote: > > > We've had a lot of luck with a very similar approach. Ours is in > > > Python, only supports x86, and isn't as complete; it also tries > > > less hard to look like a DSL. But we like it. If anyone's > > > interested, we'd be happy to post. > > How do these things differ from MOSDEF (other than having a > disassembler?) > > -- > --- > Thomas H. Ptacek // matasano security > read us on the web: http://www.matasano.com/log > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20070723/05c689f2/attachment.htm From tqbf at matasano.com Mon Jul 23 11:20:47 2007 From: tqbf at matasano.com (Thomas Ptacek) Date: Mon, 23 Jul 2007 10:20:47 -0500 Subject: [Dailydave] Announcing metasm In-Reply-To: References: <20070720211150.GB3418@cr0.org> <1df0a410707211622m6a2c38fam7bf75593013d189e@mail.gmail.com> <46A3744D.4020009@immunityinc.com> <1df0a410707220941y27a0543ak35fdb05abd672034@mail.gmail.com> Message-ID: <1df0a410707230820q75480e70g6a2588f52acf5bc6@mail.gmail.com> I'm pretty sure I'm one of 6,398 different people doing this, but we're working with a debugger driven by runtime dynamic code generation instead of OS debugger hooks; our targets are programs that aggressively detect debuggers, emulation, and program text manipulation. "Debugger" is generous; I mean, "code capable of breakpointing, inspecting, and modifying a remote execution context". I quickly read the metasm code this weekend and, unless I missed it, they didn't implement a parser; they just exploit Ruby's terseness to make it look like assembly syntax. Parsing assembly syntax seems like a complete waste of time; it's a wretched language. On 7/23/07, Dave Aitel wrote: > Is this debugger something you'd want integrated with Immunity Debugger? > When you say "debugger that runs over firewire" do you mean kinda like > WinDBG does when you're trying to do kernel debugging? I'm writing a kernel > exploit all day today, but no chance of setting up WinDBG to do it - it's > almost easier just to use memory dumps and !analyze -v. The WinDBG UI is > almost as bad as SPIKE Proxy's. One thing MOSDEF is not good at is > enumerating all the different ways to add two numbers together. We only put > one kind of encoding into the assembler and changing it now would be quite > difficult. But we're optimized for shellcode size, and speed, while > remaining pure-Python. Which is annoying because those are all polar > opposites. > > What dialect of assembler is it that metasm implements? Is that NASM-like? > > -dave > > > > On 7/22/07, Thomas Ptacek < tqbf at matasano.com> wrote: > > > > I've learned not to benchmark ideas against MOSDEF; it's dispiriting. > > > > The difference between my code and yours, apart from maturity and > > originality, is that yours focuses on assembly language and mine > > focuses on a class hierarchy for opcodes. I wanted to see how far I > > could get using Python as a superficial IL for x86. > > > > My goal isn't shellcode; it's process[or] manipulation. I used it to > > write a debugger to run over firewire. > > > > > Thomas Ptacek wrote: > > > > We've had a lot of luck with a very similar approach. Ours is in > > > > Python, only supports x86, and isn't as complete; it also tries > > > > less hard to look like a DSL. But we like it. If anyone's > > > > interested, we'd be happy to post. > > > How do these things differ from MOSDEF (other than having a > disassembler?) > > > > -- > > --- > > Thomas H. Ptacek // matasano security > > read us on the web: http://www.matasano.com/log > > _______________________________________________ > > Dailydave mailing list > > Dailydave at lists.immunitysec.com > > http://lists.immunitysec.com/mailman/listinfo/dailydave > > > > -- --- Thomas H. Ptacek // matasano security read us on the web: http://www.matasano.com/log From alex at sotirov.net Mon Jul 23 17:11:16 2007 From: alex at sotirov.net (Alexander Sotirov) Date: Mon, 23 Jul 2007 14:11:16 -0700 Subject: [Dailydave] The Pwnie Awards! Message-ID: <20070723211116.GA8360@dsl093-068-003.sfo1.dsl.speakeasy.net> The Pwnie Awards are an annual award ceremony celebrating the achivements and failures of security researchers and the security community. It will feature awards such as: * Pwnie for Best Server-Side Bug * Pwnie for Best Client-Side Bug * Pwnie for Mass 0wnage * Pwnie for Most Innovative Research * Pwnie for Lamest Vendor Response * Pwnie for Most Overhyped Bug ...and much more! Nominations are open until the end of the week. The ceremony will take place next week in Las Vegas, stay tuned for more announcements. Check it out: http://pwnie-awards.org/ Please send feedback to info at pwnie-awards.org Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available Url : http://lists.immunitysec.com/pipermail/dailydave/attachments/20070723/f7dce095/attachment.pgp From jt at cr0.org Tue Jul 24 08:52:50 2007 From: jt at cr0.org (Julien TINNES) Date: Tue, 24 Jul 2007 14:52:50 +0200 Subject: [Dailydave] Announcing metasm In-Reply-To: <46A3744D.4020009@immunityinc.com> References: <20070720211150.GB3418@cr0.org> <1df0a410707211622m6a2c38fam7bf75593013d189e@mail.gmail.com> <46A3744D.4020009@immunityinc.com> Message-ID: <200707241452.50349.jt@cr0.org> On Sunday 22 July 2007 17:14:21 Dave Aitel wrote: > How do these things differ from MOSDEF (other than having a disassembler?) > > Is the goal here an injectable proglet session or just a nice way to > assembler/disassemble shellcode? > Metasm is an assembly manipulation suite. Its purpose is to be a bit more generic than a shellcode compiler, even if it has clearly been developed with security tools (and especially exploits) in mind. It can be trivially used to assemble/disassemble shellcodes but it would be perfectly possible to implement a MOSDEF-like proglet session manager on top of it. If you want an example of metasm in action for dynamic shellcode generation, you can take a look at our remote kernel exploit for Madwifi in Metasploit's trunk (madwifi_giwscan_cb.rb). Even if this example doesn't rely too much on advanced features you can still see how we use .pad and .offset together and how we dynamically inject a Metasploit userland shellcode by using relocations (metasm has full relocation support). If you want to see more advanced usages, take a look at the 'samples' directory, for instance win32hooker-advanced.rb. This shows how you can find a process, a library mapped in this process and patch every exported function by using Metasm. -- Julien TINNES http://www.cr0.org From tqbf at matasano.com Tue Jul 24 09:09:23 2007 From: tqbf at matasano.com (Thomas Ptacek) Date: Tue, 24 Jul 2007 08:09:23 -0500 Subject: [Dailydave] Announcing metasm In-Reply-To: <200707241421.16237.jt@cr0.org> References: <20070720211150.GB3418@cr0.org> <1df0a410707230820q75480e70g6a2588f52acf5bc6@mail.gmail.com> <200707241421.16237.jt@cr0.org> Message-ID: <1df0a410707240609o7674bd7bxa66bb1be540d8be0@mail.gmail.com> Well, then, I'm clearly wrong! I read your opcode classes and your sample code and was impressed by how much you got Ruby to look like assembly. On 7/24/07, Julien TINNES wrote: > On Monday 23 July 2007 17:20:47 Thomas Ptacek wrote: > > I'm pretty sure I'm one of 6,398 different people doing this, but > > we're working with a debugger driven by runtime dynamic code > > generation instead of OS debugger hooks; our targets are programs that > > aggressively detect debuggers, emulation, and program text > > manipulation. > > > > "Debugger" is generous; I mean, "code capable of breakpointing, > > inspecting, and modifying a remote execution context". > > > > I quickly read the metasm code this weekend and, unless I missed it, > > they didn't implement a parser; they just exploit Ruby's terseness to > > make it look like assembly syntax. Parsing assembly syntax seems like > > a complete waste of time; it's a wretched language. > > > > Hello, > > Of course there is a parser! > I don't understand how you could miss it, given that it's implemented > generically in the top level parse.rb file and then specialised per > architecture in /parse.rb. > The GCC compatible preprocessor is implemented in preprocessor.rb. > > -- > Julien TINNES > http://www.cr0.org > -- --- Thomas H. Ptacek // matasano security read us on the web: http://www.matasano.com/log From ergosum at neurosecurity.com Tue Jul 24 14:08:01 2007 From: ergosum at neurosecurity.com (ergosum) Date: Tue, 24 Jul 2007 20:08:01 +0200 Subject: [Dailydave] Dangling pointers exploitation Message-ID: <200707242008.01760.ergosum@neurosecurity.com> Hello all, I would like to know what are people guessing the new dangling pointer reliable exploitation method is about. From this (http://searchsecurity.techtarget.com/originalContent/0,289142,sid14_gci1265116,00.html) I get that Thomas has been asked already ;) Lets guess a little bit, some ideas? Cheers -- http://www.neurosecurity.com "We must be the change we wish to see in the world" Mahatma Gandhi From tqbf at matasano.com Tue Jul 24 22:35:32 2007 From: tqbf at matasano.com (Thomas Ptacek) Date: Tue, 24 Jul 2007 21:35:32 -0500 Subject: [Dailydave] Dangling pointers exploitation In-Reply-To: <200707242008.01760.ergosum@neurosecurity.com> References: <200707242008.01760.ergosum@neurosecurity.com> Message-ID: <1df0a410707241935k2f6a7749r3d125bec8836380b@mail.gmail.com> Let me just qualify that I was talking about the whole class of wild-pointer bugs. On 7/24/07, ergosum wrote: > Hello all, > I would like to know what are people guessing the new dangling pointer > reliable exploitation method is about. From this > (http://searchsecurity.techtarget.com/originalContent/0,289142,sid14_gci1265116,00.html) > I get that Thomas has been asked already ;) > > Lets guess a little bit, some ideas? > > Cheers > > -- > http://www.neurosecurity.com > > "We must be the change we wish to see in the world" > Mahatma Gandhi > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave > -- --- Thomas H. Ptacek // matasano security read us on the web: http://www.matasano.com/log From jf at danglingpointers.net Wed Jul 25 20:06:27 2007 From: jf at danglingpointers.net (jf) Date: Thu, 26 Jul 2007 00:06:27 +0000 (UTC) Subject: [Dailydave] Dangling pointers exploitation In-Reply-To: <1df0a410707241935k2f6a7749r3d125bec8836380b@mail.gmail.com> References: <200707242008.01760.ergosum@neurosecurity.com> <1df0a410707241935k2f6a7749r3d125bec8836380b@mail.gmail.com> Message-ID: > Let me just qualify that I was talking about the whole class of > wild-pointer bugs. how would it be any different than ptr+overflowed_offset/array[negative_index]/et cetera bugs? perhaps the guys found a new way of reliably exploiting a very specific form of dangling pointer bugs, but i dont see how it could possibly qualify as being a new class of vulns, nor can i think of anyone who has ever said a dangling pointer was a QA issue and not a security issue From tqbf at matasano.com Wed Jul 25 13:02:32 2007 From: tqbf at matasano.com (Thomas Ptacek) Date: Wed, 25 Jul 2007 12:02:32 -0500 Subject: [Dailydave] Dangling pointers exploitation In-Reply-To: References: <200707242008.01760.ergosum@neurosecurity.com> <1df0a410707241935k2f6a7749r3d125bec8836380b@mail.gmail.com> Message-ID: <1df0a410707251002h5e82c313n6b3e77fdfd5fe8ef@mail.gmail.com> Unitialized automatic variables and use-after-free variables seem of-a-kind: you have a pointer who's value seems unpredictable but is in fact strongly influenced by the execution environment which is in turn often influenced by inputs and timing. On 7/25/07, jf wrote: > > Let me just qualify that I was talking about the whole class of > > wild-pointer bugs. > > how would it be any different than > ptr+overflowed_offset/array[negative_index]/et cetera bugs? > > perhaps the guys found a new way of reliably exploiting a very specific > form of dangling pointer bugs, but i dont see how it could possibly > qualify as being a new class of vulns, nor can i think of anyone who has > ever said a dangling pointer was a QA issue and not a security issue > -- --- Thomas H. Ptacek // matasano security read us on the web: http://www.matasano.com/log From jf at danglingpointers.net Wed Jul 25 20:51:22 2007 From: jf at danglingpointers.net (jf) Date: Thu, 26 Jul 2007 00:51:22 +0000 (UTC) Subject: [Dailydave] Dangling pointers exploitation In-Reply-To: <1df0a410707251002h5e82c313n6b3e77fdfd5fe8ef@mail.gmail.com> References: <200707242008.01760.ergosum@neurosecurity.com> <1df0a410707241935k2f6a7749r3d125bec8836380b@mail.gmail.com> <1df0a410707251002h5e82c313n6b3e77fdfd5fe8ef@mail.gmail.com> Message-ID: Didnt halvar already talk about unitialized automatic/local variables? and how is a use-after-free condition any different than a double free (other than you get to skip the second free)? On Wed, 25 Jul 2007, Thomas Ptacek wrote: > Date: Wed, 25 Jul 2007 12:02:32 -0500 > From: Thomas Ptacek > To: jf > Cc: ergosum at neurosecurity.com, dailydave at lists.immunitysec.com > Subject: Re: [Dailydave] Dangling pointers exploitation > > Unitialized automatic variables and use-after-free variables seem > of-a-kind: you have a pointer who's value seems unpredictable but is > in fact strongly influenced by the execution environment which is in > turn often influenced by inputs and timing. > > On 7/25/07, jf wrote: > > > Let me just qualify that I was talking about the whole class of > > > wild-pointer bugs. > > > > how would it be any different than > > ptr+overflowed_offset/array[negative_index]/et cetera bugs? > > > > perhaps the guys found a new way of reliably exploiting a very specific > > form of dangling pointer bugs, but i dont see how it could possibly > > qualify as being a new class of vulns, nor can i think of anyone who has > > ever said a dangling pointer was a QA issue and not a security issue > > > > > From tqbf at matasano.com Wed Jul 25 13:19:04 2007 From: tqbf at matasano.com (Thomas Ptacek) Date: Wed, 25 Jul 2007 12:19:04 -0500 Subject: [Dailydave] Dangling pointers exploitation In-Reply-To: References: <200707242008.01760.ergosum@neurosecurity.com> <1df0a410707241935k2f6a7749r3d125bec8836380b@mail.gmail.com> <1df0a410707251002h5e82c313n6b3e77fdfd5fe8ef@mail.gmail.com> Message-ID: <1df0a410707251019o3264999dlaf952de26df35623@mail.gmail.com> We're getting into a semantic argument I'm not interested in. The "class" of vulnerabilities I'm considering are "pointers that take what appears to be an unpredictable wild value, where attackers can influence either the value of the pointer or the memory the pointer points at". That class includes Halvar's stale stack frames, use-after-free, Dowd's Sendmail exception-safety hole, and C++ STL iterator invalidations. I'm pretty sure we agree there are similarities here. I'm totally uninterested in who-invented-what. I'm very interested in new techniques to trigger this class of vulnerabilities. Which is what I told Dennis. =) On 7/25/07, jf wrote: > Didnt halvar already talk about unitialized automatic/local variables? and > how is a use-after-free condition any different than a double free (other than you > get to skip the second free)? > > > > On Wed, 25 Jul 2007, Thomas Ptacek wrote: > > > Date: Wed, 25 Jul 2007 12:02:32 -0500 > > From: Thomas Ptacek > > To: jf > > Cc: ergosum at neurosecurity.com, dailydave at lists.immunitysec.com > > Subject: Re: [Dailydave] Dangling pointers exploitation > > > > Unitialized automatic variables and use-after-free variables seem > > of-a-kind: you have a pointer who's value seems unpredictable but is > > in fact strongly influenced by the execution environment which is in > > turn often influenced by inputs and timing. > > > > On 7/25/07, jf wrote: > > > > Let me just qualify that I was talking about the whole class of > > > > wild-pointer bugs. > > > > > > how would it be any different than > > > ptr+overflowed_offset/array[negative_index]/et cetera bugs? > > > > > > perhaps the guys found a new way of reliably exploiting a very specific > > > form of dangling pointer bugs, but i dont see how it could possibly > > > qualify as being a new class of vulns, nor can i think of anyone who has > > > ever said a dangling pointer was a QA issue and not a security issue > > > > > > > > > > -- --- Thomas H. Ptacek // matasano security read us on the web: http://www.matasano.com/log From jf at danglingpointers.net Wed Jul 25 21:17:31 2007 From: jf at danglingpointers.net (jf) Date: Thu, 26 Jul 2007 01:17:31 +0000 (UTC) Subject: [Dailydave] Dangling pointers exploitation In-Reply-To: <1df0a410707251019o3264999dlaf952de26df35623@mail.gmail.com> References: <200707242008.01760.ergosum@neurosecurity.com> <1df0a410707241935k2f6a7749r3d125bec8836380b@mail.gmail.com> <1df0a410707251002h5e82c313n6b3e77fdfd5fe8ef@mail.gmail.com> <1df0a410707251019o3264999dlaf952de26df35623@mail.gmail.com> Message-ID: All apologies, my intent is not to get into semantics, but rather to point out that thus far no one has presented an argument about anything new. If they really have a method for triggering some of these types of problems, then I will agree its something interesting, but I didn't get that impression from anything i've seen or heard, but rather I've heard what appears to be hype and propaganda by a reporter who either doesn't know what they're talking about, or can't properly communicate what they're talking about. If I'm wrong, then post-bh I'll say I'm wrong, but I don't think thats the case. On Wed, 25 Jul 2007, Thomas Ptacek wrote: > Date: Wed, 25 Jul 2007 12:19:04 -0500 > From: Thomas Ptacek > To: jf > Cc: ergosum at neurosecurity.com, dailydave at lists.immunitysec.com > Subject: Re: [Dailydave] Dangling pointers exploitation > > We're getting into a semantic argument I'm not interested in. The > "class" of vulnerabilities I'm considering are "pointers that take > what appears to be an unpredictable wild value, where attackers can > influence either the value of the pointer or the memory the pointer > points at". That class includes Halvar's stale stack frames, > use-after-free, Dowd's Sendmail exception-safety hole, and C++ STL > iterator invalidations. > > I'm pretty sure we agree there are similarities here. I'm totally > uninterested in who-invented-what. I'm very interested in new > techniques to trigger this class of vulnerabilities. Which is what I > told Dennis. =) > > On 7/25/07, jf wrote: > > Didnt halvar already talk about unitialized automatic/local variables? and > > how is a use-after-free condition any different than a double free (other > > than you > > get to skip the second free)? > > > > > > > > On Wed, 25 Jul 2007, Thomas Ptacek wrote: > > > > > Date: Wed, 25 Jul 2007 12:02:32 -0500 > > > From: Thomas Ptacek > > > To: jf > > > Cc: ergosum at neurosecurity.com, dailydave at lists.immunitysec.com > > > Subject: Re: [Dailydave] Dangling pointers exploitation > > > > > > Unitialized automatic variables and use-after-free variables seem > > > of-a-kind: you have a pointer who's value seems unpredictable but is > > > in fact strongly influenced by the execution environment which is in > > > turn often influenced by inputs and timing. > > > > > > On 7/25/07, jf wrote: > > > > > Let me just qualify that I was talking about the whole class of > > > > > wild-pointer bugs. > > > > > > > > how would it be any different than > > > > ptr+overflowed_offset/array[negative_index]/et cetera bugs? > > > > > > > > perhaps the guys found a new way of reliably exploiting a very specific > > > > form of dangling pointer bugs, but i dont see how it could possibly > > > > qualify as being a new class of vulns, nor can i think of anyone who has > > > > ever said a dangling pointer was a QA issue and not a security issue > > > > > > > > > > > > > > > > > > From pusscat at metasploit.com Wed Jul 25 13:51:41 2007 From: pusscat at metasploit.com (Pusscat) Date: Wed, 25 Jul 2007 13:51:41 -0400 Subject: [Dailydave] Dangling pointers exploitation In-Reply-To: <1df0a410707251002h5e82c313n6b3e77fdfd5fe8ef@mail.gmail.com> References: <200707242008.01760.ergosum@neurosecurity.com> <1df0a410707241935k2f6a7749r3d125bec8836380b@mail.gmail.com> <1df0a410707251002h5e82c313n6b3e77fdfd5fe8ef@mail.gmail.com> Message-ID: <01d701c7cee4$75cd6990$61683cb0$@com> Didn't halvar give a memory painting talk on exploiting this kind of uninitialized/"dangling" variable bug? ~ Puss -----Original Message----- From: dailydave-bounces at lists.immunitysec.com [mailto:dailydave-bounces at lists.immunitysec.com] On Behalf Of Thomas Ptacek Sent: Wednesday, July 25, 2007 1:03 PM To: jf Cc: dailydave at lists.immunitysec.com Subject: Re: [Dailydave] Dangling pointers exploitation Unitialized automatic variables and use-after-free variables seem of-a-kind: you have a pointer who's value seems unpredictable but is in fact strongly influenced by the execution environment which is in turn often influenced by inputs and timing. On 7/25/07, jf wrote: > > Let me just qualify that I was talking about the whole class of > > wild-pointer bugs. > > how would it be any different than > ptr+overflowed_offset/array[negative_index]/et cetera bugs? > > perhaps the guys found a new way of reliably exploiting a very specific > form of dangling pointer bugs, but i dont see how it could possibly > qualify as being a new class of vulns, nor can i think of anyone who has > ever said a dangling pointer was a QA issue and not a security issue > -- --- Thomas H. Ptacek // matasano security read us on the web: http://www.matasano.com/log _______________________________________________ Dailydave mailing list Dailydave at lists.immunitysec.com http://lists.immunitysec.com/mailman/listinfo/dailydave From chris.rohlf at gmail.com Wed Jul 25 14:03:24 2007 From: chris.rohlf at gmail.com (Chris Rohlf) Date: Wed, 25 Jul 2007 14:03:24 -0400 Subject: [Dailydave] Dangling pointers exploitation In-Reply-To: <1df0a410707251002h5e82c313n6b3e77fdfd5fe8ef@mail.gmail.com> References: <200707242008.01760.ergosum@neurosecurity.com> <1df0a410707241935k2f6a7749r3d125bec8836380b@mail.gmail.com> <1df0a410707251002h5e82c313n6b3e77fdfd5fe8ef@mail.gmail.com> Message-ID: <1681f2df0707251103k3982076eu55fb23cb4323d3f8@mail.gmail.com> On 7/25/07, Thomas Ptacek wrote: > Unitialized automatic variables and use-after-free variables seem > of-a-kind: you have a pointer who's value seems unpredictable but is > in fact strongly influenced by the execution environment which is in > turn often influenced by inputs and timing. The articles about this research and the upcoming presentation are pretty vague. Where were the now dangling pointers pointing to? The heap? Were they function pointers? This leaves a lot of open questions for me. Like Thomas, the first thought I had was - well if your dangling pointer points back into the heap, its entirely possible (given a program like a web server) to create specially crafted inputs that eventually will be placed where you need them - you can control these types of things. The only obstacle being the fact you have to guess where that dangling pointer points to. Unless of course you can control it the first time around. I think the biggest problem in exploiting/finding these kinds of issues is knowing whether you have a dangling pointer or not. If the program never crashes, and you don't have the source, you may never know there was an issue. I look forward to reading this presentation after everyone else because I could not black hat this year :< chris -- http://em386.blogspot.com From matt at use.net Wed Jul 25 14:06:32 2007 From: matt at use.net (Matt) Date: Wed, 25 Jul 2007 11:06:32 -0700 (PDT) Subject: [Dailydave] Dangling pointers exploitation In-Reply-To: <1df0a410707251002h5e82c313n6b3e77fdfd5fe8ef@mail.gmail.com> References: <200707242008.01760.ergosum@neurosecurity.com> <1df0a410707241935k2f6a7749r3d125bec8836380b@mail.gmail.com> <1df0a410707251002h5e82c313n6b3e77fdfd5fe8ef@mail.gmail.com> Message-ID: On Wed, 25 Jul 2007, Thomas Ptacek wrote: > Unitialized automatic variables and use-after-free variables seem > of-a-kind: you have a pointer who's value seems unpredictable but is > in fact strongly influenced by the execution environment which is in > turn often influenced by inputs and timing. Right. It's almost as if going through the Purify and Insure++ documentation from 10+ years ago is a veritable gold-mine for new types of exploitable bugs. -- tangled strands of DNA explain the way that I behave. http://www.clock.org/~matt From pageexec at freemail.hu Wed Jul 25 14:43:08 2007 From: pageexec at freemail.hu (pageexec at freemail.hu) Date: Wed, 25 Jul 2007 20:43:08 +0200 Subject: [Dailydave] Dangling pointers exploitation In-Reply-To: <1df0a410707251002h5e82c313n6b3e77fdfd5fe8ef@mail.gmail.com> References: <200707242008.01760.ergosum@neurosecurity.com>, , <1df0a410707251002h5e82c313n6b3e77fdfd5fe8ef@mail.gmail.com> Message-ID: <46A7B5DC.24956.16694B24@pageexec.freemail.hu> On 25 Jul 2007 at 12:02, Thomas Ptacek wrote: > you have a pointer who's value seems unpredictable but is > in fact strongly influenced by the execution environment which is in > turn often influenced by inputs and timing. such as... a saved return address on the stack? isn't that kinda old news these days? ;-) From tqbf at matasano.com Wed Jul 25 15:03:12 2007 From: tqbf at matasano.com (Thomas Ptacek) Date: Wed, 25 Jul 2007 14:03:12 -0500 Subject: [Dailydave] Dangling pointers exploitation In-Reply-To: <46A7B5DC.24956.16694B24@pageexec.freemail.hu> References: <200707242008.01760.ergosum@neurosecurity.com> <1df0a410707251002h5e82c313n6b3e77fdfd5fe8ef@mail.gmail.com> <46A7B5DC.24956.16694B24@pageexec.freemail.hu> Message-ID: <1df0a410707251203w128ee76ewf7dc400abb0741cc@mail.gmail.com> I'm not sure "saved return address on the stack" is the real vector for uninitialized variables. On 7/25/07, pageexec at freemail.hu wrote: > On 25 Jul 2007 at 12:02, Thomas Ptacek wrote: > > > you have a pointer who's value seems unpredictable but is > > in fact strongly influenced by the execution environment which is in > > turn often influenced by inputs and timing. > > such as... a saved return address on the stack? isn't that kinda old > news these days? ;-) > > -- --- Thomas H. Ptacek // matasano security read us on the web: http://www.matasano.com/log From pageexec at freemail.hu Wed Jul 25 15:29:43 2007 From: pageexec at freemail.hu (pageexec at freemail.hu) Date: Wed, 25 Jul 2007 21:29:43 +0200 Subject: [Dailydave] Dangling pointers exploitation In-Reply-To: <1df0a410707251203w128ee76ewf7dc400abb0741cc@mail.gmail.com> References: <200707242008.01760.ergosum@neurosecurity.com>, <46A7B5DC.24956.16694B24@pageexec.freemail.hu>, <1df0a410707251203w128ee76ewf7dc400abb0741cc@mail.gmail.com> Message-ID: <46A7C0C7.17956.1693EF76@pageexec.freemail.hu> On 25 Jul 2007 at 14:03, Thomas Ptacek wrote: > I'm not sure "saved return address on the stack" is the real vector > for uninitialized variables. it is not, nor were you talking about unitialized variables per se, but this entirely 'new' class of bugs of wild pointers, which according to you means: > you have a pointer who's value seems unpredictable but is > in fact strongly influenced by the execution environment which is in > turn often influenced by inputs and timing. you tell me why an overwritten return address doesn't qualify ;). From krpatasec at gmail.com Wed Jul 25 18:11:03 2007 From: krpatasec at gmail.com (Tyler Krpata) Date: Wed, 25 Jul 2007 18:11:03 -0400 Subject: [Dailydave] Dangling pointers exploitation In-Reply-To: <1df0a410707251203w128ee76ewf7dc400abb0741cc@mail.gmail.com> References: <200707242008.01760.ergosum@neurosecurity.com> <1df0a410707251002h5e82c313n6b3e77fdfd5fe8ef@mail.gmail.com> <46A7B5DC.24956.16694B24@pageexec.freemail.hu> <1df0a410707251203w128ee76ewf7dc400abb0741cc@mail.gmail.com> Message-ID: <9d3431d0707251511o6e786229n20bbca2ab5e54b28@mail.gmail.com> Keeping in mind that "uninitialized" and "previously valid" have some important differences. On 7/25/07, Thomas Ptacek wrote: > I'm not sure "saved return address on the stack" is the real vector > for uninitialized variables. > > On 7/25/07, pageexec at freemail.hu wrote: > > On 25 Jul 2007 at 12:02, Thomas Ptacek wrote: > > > > > you have a pointer who's value seems unpredictable but is > > > in fact strongly influenced by the execution environment which is in > > > turn often influenced by inputs and timing. > > > > such as... a saved return address on the stack? isn't that kinda old > > news these days? ;-) > > > > > > > -- > --- > Thomas H. Ptacek // matasano security > read us on the web: http://www.matasano.com/log > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave > From asotirov at determina.com Wed Jul 25 18:37:39 2007 From: asotirov at determina.com (Alexander Sotirov) Date: Wed, 25 Jul 2007 15:37:39 -0700 Subject: [Dailydave] Dangling pointers exploitation In-Reply-To: <200707242008.01760.ergosum@neurosecurity.com> References: <200707242008.01760.ergosum@neurosecurity.com> Message-ID: <46A7D0B3.3080907@determina.com> The articles defines dangling pointers as pointers that refer to an invalid object, often because the referenced object was deleted without changing the value of the pointer. This type of bugs is also known as "use-after-free" I think these bugs belong to a class best described as "uninitialized data vulnerabilities". In practice there is little difference between data that was never initialized and data that was freed and then reused. The exploitation methods are similar in both cases. Halvar has done some work on exploiting uninitialized data on the stack [1]. My Heap Feng Shui presentation [2] describes heap manipulation techniques for exploiting uninitialized data on the heap. The sample exploit code released my presentation shows how to exploit an ActiveX control that uses random data as an object pointer. I am sure that there are other exploits that use similar techniques. The article mentions that the Watchfire technique was originally developed for the IIS 5.1 bug (CVE-2005-4360), which was publicly reported as a DoS in 2005 and remained unpatched until MS07-041. I did some analysis of it back when it was disclosed. This bug is triggered by sending an HTTP request for /_vti_bin/.dll/:~0 exactly four times. The problem is caused by an incorrectly decremented reference counter for a CWamInfo object. If the request URL is malformed, the counter is decremented by one, but the reference to the object is not invalidated. The counter starts at 3. After three invalid request the counter reaches 0 and the CWamInfo object is freed. Since the number of real references to the object is still 3, the next request will dereference the pointer to the old data. To exploit this vulnerability we need to do the following: 1. Cause a few allocations for 560 bytes to empty the lookaside. 2. Send two invalid requests. This will decrement the CWamInfo refcounter to 1 3. Send a request that allocates and frees 560 bytes. We need to put a pointer to our shellcode at offset 0xC in this block. Freeing the block will put it on the lookaside. 4. Send the third invalid request. This will free the 560 byte CWamInfo object and put it on the lookaside. The vtable pointer of the object will be overwritten with the address of the block freed in step 3. 5. Send a fourth invalid request. IIS will call the virtual function at offset 0xC in the vtable of the freed CWamInfo object. Since we control the pointer there, we get shellcode execution. Figuring out how to do steps 1 and 3 reliably is the main difficulty in exploiting this vulnerability. I don't know of a good generic way to exploit these types of bugs. There are common patterns in uninitialized data exploits, but the way you do heap allocations is different for each application. If Watchfire has discovered a better exploitation method for these bugs, it would be great and I'll be eager to hear about it. If their technique is something similar to the one above, then it's nothing new. The fear mongering in the article is great though. We definitely need more of that in the security industry: "Afek and Sharabani's discovery is a major step forward and a scary one at that, given the ubiquity of this kind of coding error." Take care, Alex [1] http://www.blackhat.com/presentations/bh-europe-06/bh-eu-06-Flake.pdf [2] http://www.determina.com/security.research/presentations/bh-eu07/ From dr at kyx.net Tue Jul 31 17:26:30 2007 From: dr at kyx.net (Dragos Ruiu) Date: Tue, 31 Jul 2007 14:26:30 -0700 Subject: [Dailydave] Really, really, penultimate, PacSec CFP deadline, Aug 10. Message-ID: <200707311426.30868.dr@kyx.net> Some folks have been trying to convince us to extend deadlines, so being the sticklers we are, we said: no way... But they convinced us. So to be fair - this is a heads up for others who didn't have time to submit. :-) We'll try to turn around the selection reviews ASAP, before the end of August for those who submitted. cheers, --dr P.s. The gentleman from McAfee who phoned me about his submission whose name I've forgotten, we didn't get your mail, please get back in touch. -- World Security Pros. Cutting Edge Training, Tools, and Techniques Tokyo, Japan November 29/30 - 2007 http://pacsec.jp pgpkey http://dragos.com/ kyxpgp