From ergosum at neurosecurity.com Tue Apr 1 10:08:41 2008 From: ergosum at neurosecurity.com (ergosum) Date: Tue, 1 Apr 2008 16:08:41 +0200 Subject: [Dailydave] A small fun Python puzzle In-Reply-To: <47F14AE9.5060001@handcraftedcomputers.com.au> References: <47F11B17.7050303@immunityinc.com> <47F14AE9.5060001@handcraftedcomputers.com.au> Message-ID: <200804011608.41986.ergosum@neurosecurity.com> Hi all, > results in: > >>> for l in [100000, 1000000, 5000000, 10000000]: > > ... print '%10d %f' % (l, test(l)) > ... > 100000 0.006711 > 1000000 0.764886 > 5000000 28.554786 > 10000000 111.738498 > > (wow - so not linear ...) > This is very interesting. I'm not a python ninja but AFAIK (quoting from: http://etutorials.org/Programming/Python+tutorial/Part+III+Python+Library+and+Extension+Modules/Chapter+17. +Testing,+Debugging,+and+Optimizing/17.4+Optimization/): "Chaining two lists of length N1 and N2 is O(N1+N2). Multiplying a list of length N by the number M is O(N*M). Accessing or rebinding any list item is O(1) (also known as constant time, meaning that the time taken does not depend on how many items are in the list). len( ) on a list is also O(1). Accessing any slice of length M is O(M). Rebinding a slice of length M with one of identical length is also O(M). Rebinding a slice of length M1 with one of different length M2 is O(M1+M2+N1), where N1 is the number of items after the slice in the target list." So if this is true, slicing data[1024:] should be O(M) where M = 100000, 1000000, 5000000, 10000000 respectively, while slicing data[i:i+1024] should always be O(N) where N = 1024. There is a huge gain here that accounts for the more or less homogeneous times of the second algorithm. Nevertheless it puzzles me why the slicing operation isn't linear. Anyone with a better python internal knowledge can throw some light? -- http://www.neurosecurity.com "We must be the change we wish to see in the world" Mahatma Gandhi From dave at immunityinc.com Tue Apr 1 13:45:23 2008 From: dave at immunityinc.com (Dave Aitel) Date: Tue, 01 Apr 2008 13:45:23 -0400 Subject: [Dailydave] Announcement: RE-DB mailing list Message-ID: <47F274B3.3080704@immunityinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 http://lists.immunityinc.com/mailman/listinfo/re-db Immunity and Zynamics are happy to offer a new mailing list to discuss a common reverse engineering database format. Early work on this SQL Schema has already been useful. There are exporters for Immunity Debugger and other industry tools to the schema which can then be natively browsed by Zynamics' BinNavi. Why is this important to you? It's important because the future is not one where each RE tool you use sits in a small cave of data by itself. For example, if you want to take multiple runs of a program and look at how different inputs are handled and use that to help generate fixed points for a binary differ (such as Zynamics BinDiff) it helps to have a database format that allows you to transfer data like that back and forth. Likewise, your binary analysis data needs to be dealt with in a way that scales up past a fifty meg binary. And there's no good reason to touch every binary once per person or once per tool. The future of reverse engineering is having one RE-DB per team, with limitless possibilities as your toolkit works together to solve your RE problems. Help us build it by joining the discussion. Thanks, Dave Aitel Immunity, Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH8nSztehAhL0gheoRAmTAAJ918uKhB9/5I+VrUiM1nvUcxx3OkACdEQtm 9Sr/PK1EQR+D60BYyY4Ob30= =njfx -----END PGP SIGNATURE----- From jeremy at austin.ibm.com Tue Apr 1 15:19:56 2008 From: jeremy at austin.ibm.com (Jeremy Kelley) Date: Tue, 1 Apr 2008 14:19:56 -0500 Subject: [Dailydave] A small fun Python puzzle In-Reply-To: <47F25CCF.1020302@immunityinc.com> References: <47F11B17.7050303@immunityinc.com> <20080331200616.GA26316@ark.ibm.com> <47F22F9A.6020200@immunityinc.com> <20080401132510.GA21046@ark.ibm.com> <47F23E10.9090502@immunityinc.com> <20080401160207.GB19477@ark.ibm.com> <47F25CCF.1020302@immunityinc.com> Message-ID: <20080401191956.GB7647@ark.ibm.com> The proprietor said to send this to the list. -j Quoting Dave Aitel (dave at immunityinc.com): |> -----BEGIN PGP SIGNED MESSAGE----- |> Hash: SHA1 |> |> Jeremy Kelley wrote: |> | btw, you're using the StringIO module to correct the problem, right? |> | I forgot to mention that yesterday. |> | |> | -j |> | |> Nah, we just read in 1024 bytes of the file at a time ... makes life a lot |> easier. :> |> |> - -dave | | I typed up an email saying how StringIO would be faster than multiple | reads of a filehandle then decided to write a quick test. I was wrong. | | My tests actually show that on avg, multiple reads from a file handle | (on my laptop only) are approximately 5-15% faster for file sizes up to | 32000000 bytes. Then, they even out and StringIO becomes a little | faster until the size of the file hits a certain size and my laptop ram | fills up. At that point, StringIO is twice the time as reading from the | file handle. | | So, in summary. I'm wrong about StringIO. Yay for learning! | | That's my .02. I'll let it die now. :) | | -j -- Jeremy Kelley Sr. Threat Analyst gpg 1024D/E0DF8B2D 4BC3 B8B5 5B42 CC8E B6A9 2E85 32D3 C51C E0DF 8B2D That's the problem with science. You've got a bunch of empiricists trying to describe things of unimaginable wonder. -Bill Watterson From dave at immunityinc.com Tue Apr 1 17:11:24 2008 From: dave at immunityinc.com (Dave Aitel) Date: Tue, 01 Apr 2008 17:11:24 -0400 Subject: [Dailydave] Why you care about this sort of Python bug. Message-ID: <47F2A4FC.8000908@immunityinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 As many people noticed, this is it. Essentially the following line is equivalent with strdup(data+1024). ~ data=data[1024:] Below you can see an exponential increase in time... $ time python /tmp/test.py 1000 user 0m0.019s $ time python /tmp/test.py 10000 user 0m0.043s $ time python /tmp/test.py 100000 user 0m2.251s $ time python /tmp/test.py 1000000 user 6m45.435s Code for test.py: import sys count=int(sys.argv[1]) data="A"*count for i in xrange(len(data)): ~ data=data[1:] Urls to review, although there's no "one document" that really sums this up. http://www.skymind.com/~ocrow/python_string/ http://wiki.python.org/moin/PythonSpeed/PerformanceTips For example, in Python 2.5: 'string += another_string' or "string = string + anotherstring" is O(1) thanks to some optimization. This, on the other hand, is exponential: dave at ubuntu:~$ cat /tmp/test2.py import sys count=int(sys.argv[1]) data="" datas=[] for i in xrange(count): ~ data2=data #temporary variable ~ data=data2+"A" Why do you care? Because these bugs can get quite complex. Often you have your "strdup()-like" operation inside a function which is inside a loop. And when your IDS is running Lua and an attacker forces this path, this means a CPU-exhaustion bug (and lots of missed packets). If you're running a remote scanner against someone, this means you get tar-pitted when you hit their malicious server. - -dave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH8qT8tehAhL0gheoRAtLdAKCDEmyeR2pCFhuqMhIA5AdrW+3a4wCfSHv3 fMs+URI/fOuk5opQGYD+z4s= =YDY8 -----END PGP SIGNATURE----- From hfortier at recon.cx Wed Apr 2 07:37:13 2008 From: hfortier at recon.cx (Hugo Fortier) Date: Wed, 02 Apr 2008 07:37:13 -0400 Subject: [Dailydave] Recon 2008 CFP last call, early registration open Message-ID: <47F36FE9.4060804@recon.cx> + + + + + + + + + \ / + _ - _+_ - ,__ _=. .:. /=\ _|===|_ ||::| | | _|. | | | | | | __===_ -=- ||::| |==| | | __ |.:.| /\| |:. | | | | .|| : |||::| | |- |.:|_|. :__ |.: |--|==| | .| |_ | ' |. ||. |||:.| __|. | |_|. | |.|...||---| |==| | | | |_--. || |||. | | | | |. | | |::.||: .| |==| | . : |=|===| :|| . ||| .| |:.| .| | | | |:.:|| . | |==| | |=|===| . |' | | | | | | | |' : . | ; ; ' | ' : ` : ' . ' . . : ' . R E C O N 2 0 0 8 . http://recon.cx/2008/ ` . . ' . june 13 to 15, 2008 montreal, quebec + The early registration for the conference is now open. + We are offering three training courses this year. -Advanced Reverse Engineering by Nicolas Brulez -Binary vulnerabilities and Exploit Writing by Gerardo 'gera' Richarte -Binary Literacy: Static Reverse Engineering by Rolf Rolles check http://recon.cx/2008/training.html for more details + There is one month left before the end of the call for paper check http://recon.cx/2008/recon2008-cfp.txt for details ATH0++ N0 C4RR13R From lifeasageek at gmail.com Wed Apr 2 01:40:52 2008 From: lifeasageek at gmail.com (Depapepe Lee) Date: Wed, 2 Apr 2008 14:40:52 +0900 Subject: [Dailydave] Congrats to Charlie Miller ... In-Reply-To: <68dd869f0803280328p77b8e461qf4a12c0ac84f4f30@mail.gmail.com> References: <68dd869f0803280328p77b8e461qf4a12c0ac84f4f30@mail.gmail.com> Message-ID: We've done this vulneability on Safari for Windows XP, and it turns out that it perfectly works well. By the way, how did you get that patched information? Does it exact one exploited at this CanSecWest? On Fri, Mar 28, 2008 at 7:28 PM, Rhys Kidd wrote: > http://trac.webkit.org/projects/webkit/changeset/31388 > > > On 28/03/2008, Dave Aitel wrote: > > > > > > For bringing some old school beef and winning a mac air at cansecwest! > > > > Is safari on the vista box vuln too? After that iTunes update it > > should be fair game. > > _______________________________________________ > > Dailydave mailing list > > Dailydave at lists.immunitysec.com > > http://lists.immunitysec.com/mailman/listinfo/dailydave > > > > > _______________________________________________ > 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/20080402/836ab4ea/attachment.html From lorgandon at gmail.com Tue Apr 1 18:43:11 2008 From: lorgandon at gmail.com (Imri Goldberg) Date: Wed, 02 Apr 2008 01:43:11 +0300 Subject: [Dailydave] Why you care about this sort of Python bug. In-Reply-To: <47F2A4FC.8000908@immunityinc.com> References: <47F2A4FC.8000908@immunityinc.com> Message-ID: <47F2BA7F.3080705@gmail.com> Dave Aitel wrote: > As many people noticed, this is it. Essentially the following line is > equivalent with strdup(data+1024). > ~ data=data[1024:] > > Below you can see an exponential increase in time... You cheated a little bit here - you gave it exponential increasing size of input. The time should grow only by O(n^2), which is still slow enough :) > $ time python /tmp/test.py 1000 > user 0m0.019s > > $ time python /tmp/test.py 10000 > user 0m0.043s > > $ time python /tmp/test.py 100000 > user 0m2.251s > > $ time python /tmp/test.py 1000000 > user 6m45.435s > > Code for test.py: > import sys > count=int(sys.argv[1]) > data="A"*count > for i in xrange(len(data)): > ~ data=data[1:] Cheers, Imri ------------------------- Imri Goldberg www.algorithm.co.il/blogs www.imri.co.il ------------------------- Insert Signature Here ------------------------- From anthony at secure-dna.com Wed Apr 2 21:45:02 2008 From: anthony at secure-dna.com (Anthony Giandomenico) Date: Wed, 02 Apr 2008 15:45:02 -1000 Subject: [Dailydave] ShakaCon 2008 Message-ID: It's here! Once again, we're calling upon Hawaii's vast knowledge-pool of information security, IT audit and compliance professionals; students interested in learning real-world security applications, technologies, and methodologies; ethical hackers (emphasis on ethical); and otherwise security enthusiasts. Shakacon - Hawaii's first and only security conference of its kind - is back for another week of training, education, and information dedicated to the security community within Hawaii and Globally. We are looking for people locally to present informative sessions in the security industry that will provide both current research and practical experience in a broad range of security topics. Please review the following for more information on presenting at ShakaCon 2008. * * * * * * * * * * * * * * * HONOLULU, HI - Following the great success that we had at the first Shakacon - the second annual Shakacon security conference - where industry, government, academia and independent experts will get together to share knowledge - will be held in the heart of Honolulu on June 10-11, 2008. One of the most beautiful places on Earth will be the backdrop for a unique conference experience. Informative sessions will present both current research and practical experience on a broad range of security topics. Shakacon will offer local, national, and international participants a casual, social learning environment designed to present a "holistic" security view and the opportunity to network with peers and fellow enthusiasts in a relaxed setting. During the day, sessions will include: best practices, case studies, research projects, etc. covering all different aspects of security to offer a layered view of the security landscape. Expect topics as wide ranging as security training to forensic investigations. There will be something for everyone. After-hours, the learning will continue with exciting events and contests that will test skills and knowledge. Papers may be submitted to the review committee by April 18th, 2008. Slides for your papers must be submitted by May 9th, 2008. There are only a limited number of speaking sessions for which the conference organizers will provide travel and accommodations. E-Mail your proposal including: brief topic summary, paper, and bio to info at shakacon.org. Your subject line should include: "Submission: , " The audience will be a broad mix of professional, academic, and enthusiast, so we welcome both technical and non-technical submissions on all aspects of security. The key criteria are practicality and timeliness. We want to provide our attendees with materials they can take away and immediately gain benefit from. Absolutely NO SALES presentations - our attendees don't show up to hear people talk about what they can sell them or why they need your services. Proposals should include: 1. Name, address, and contact info. 2. Employer and/or affiliations. 3. Brief biography. 4. Presentation experience. 5. Topic summary. 6. Reason this topic should be considered. 7. Other publications or conferences where this material has been or will be published/submitted. Please include plain text of all information provided in the body of your email as well as any file attachments. The plain text information will be reviewed first to find the most suitable candidates. Please forward the above information to info at shakacon.org to be considered. More information, registration and hotel details, and partner deals will be posted to: http://www.shakacon.org This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20080402/9e452024/attachment.htm From michel.arboi at gmail.com Thu Apr 3 16:33:38 2008 From: michel.arboi at gmail.com (Michel Arboi) Date: Thu, 3 Apr 2008 22:33:38 +0200 Subject: [Dailydave] Why you care about this sort of Python bug. In-Reply-To: <47F2BA7F.3080705@gmail.com> References: <47F2A4FC.8000908@immunityinc.com> <47F2BA7F.3080705@gmail.com> Message-ID: On Wed, Apr 2, 2008 at 12:43 AM, Imri Goldberg wrote: > You cheated a little bit here - you gave it exponential increasing size > of input. Right > The time should grow only by O(n^2), which is still slow enough :) It seems that the execution time is roughly n^2 * 2*10^(-5) Strange... From dave at immunityinc.com Fri Apr 4 13:46:43 2008 From: dave at immunityinc.com (Dave Aitel) Date: Fri, 04 Apr 2008 13:46:43 -0400 Subject: [Dailydave] Security FAIL. Message-ID: <47F66983.4020700@immunityinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 http://blogs.the451group.com/security/?p=16 The 451 Group has an interesting article on the FAIL that is the AV industry right now. I like the last paragraph especially where they reference the "illusion of competence". As they note, having a better metric to test the AV industry (like number of people with it installed who get owned by malware) would largely benefit consumers as a whole. I wouldn't look for anything here soon. But the market is smart. When a technology doesn't work, they just move to Vista and stop buying it. - -dave P.S.http://failblog.wordpress.com/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH9mmDtehAhL0gheoRAs/gAJsFKESL9/5MKPh0VRpf1phPgVDeiwCdEvzw LfbC+7lsUmzi+Od8voudFJs= =qSAK -----END PGP SIGNATURE----- From admin at gleg.net Mon Apr 7 12:55:24 2008 From: admin at gleg.net (admin at gleg.net) Date: Mon, 07 Apr 2008 10:55:24 -0600 Subject: [Dailydave] RusCrypto2008 conf Message-ID: <20080407105524.epmx2uuku8kgk8kc@gleg.net> Hello, So RusCrypto 2008 conference is over. There were a few interesting talks, especially in "reversing" 4 section. I guess all of them should be available for download from ruscrypto.ru I talked a little about fuzzing antiviruses with block-based fuzzer, explained what is a SPIKE and how it works and also showed a few unreleased bugs. My talk is here (it is in russian) - http://gleg.net/attacking_antiviruses.ppt -- Best regards, Evgeny Legerov From fw at deneb.enyo.de Sat Apr 5 09:41:14 2008 From: fw at deneb.enyo.de (Florian Weimer) Date: Sat, 05 Apr 2008 15:41:14 +0200 Subject: [Dailydave] Why you care about this sort of Python bug. In-Reply-To: (Michel Arboi's message of "Thu, 3 Apr 2008 22:33:38 +0200") References: <47F2A4FC.8000908@immunityinc.com> <47F2BA7F.3080705@gmail.com> Message-ID: <87abk8to5h.fsf@mid.deneb.enyo.de> * Michel Arboi: >> The time should grow only by O(n^2), which is still slow enough :) > > It seems that the execution time is roughly n^2 * 2*10^(-5) > Strange... Not really. It's proportional to the number of characters copied. Python does not create string slices behind your back (at least in certain popular implementations), unlike say Java. From michel.arboi at gmail.com Sat Apr 5 11:03:26 2008 From: michel.arboi at gmail.com (Michel Arboi) Date: Sat, 5 Apr 2008 17:03:26 +0200 Subject: [Dailydave] Why you care about this sort of Python bug. In-Reply-To: <87abk8to5h.fsf@mid.deneb.enyo.de> References: <47F2A4FC.8000908@immunityinc.com> <47F2BA7F.3080705@gmail.com> <87abk8to5h.fsf@mid.deneb.enyo.de> Message-ID: On Sat, Apr 5, 2008 at 3:41 PM, Florian Weimer wrote: > Not really. It's proportional to the number of characters copied. Definitely not. The execution time of this program is O(n^2). But it is normal, though. I did not really look at the Python code first (I never wrote a single line in this language) If I understand it correctly, the program truncates the first byte of the string and starts over until all characters are deleted. It is not surprising that it has to copy the string, thus giving a N^2 time (n + n-1 + n-2 + ...) No Python bug here, as far as I can understand what Python /should/ do. [Dave Aitel] > For example, in Python 2.5: 'string += another_string' or "string = > string + anotherstring" is O(1) thanks to some optimization. This is probably true as long as the heap is not fragmented and the realloc call does not need to copy the buffer. (once again, I'm just guessing how the Python interpreter is working) From fw at deneb.enyo.de Sat Apr 5 17:05:28 2008 From: fw at deneb.enyo.de (Florian Weimer) Date: Sat, 05 Apr 2008 23:05:28 +0200 Subject: [Dailydave] Security FAIL. In-Reply-To: <47F66983.4020700@immunityinc.com> (Dave Aitel's message of "Fri, 04 Apr 2008 13:46:43 -0400") References: <47F66983.4020700@immunityinc.com> Message-ID: <871w5k6mhz.fsf@mid.deneb.enyo.de> * Dave Aitel: > http://blogs.the451group.com/security/?p=16 > > The 451 Group has an interesting article on the FAIL that is the AV > industry right now. I like the last paragraph especially where they > reference the "illusion of competence". As they note, having a better > metric to test the AV industry (like number of people with it installed > who get owned by malware) would largely benefit consumers as a whole. I > wouldn't look for anything here soon. There is a general insistence in the AV industry to test only malware which is a few weeks old. In testing, you also get sort-of competitive performance with MD5-based checking, even if the malware in question is made MD5-unique before actual deployment. I'm not sure if it's a problem for the AV companies, though. Their brands are quite strong, and the policies that guarantee them a steady revenue stream are well-enshrined industry-wide. Certainly it's not going to affect them in the current CEO cycle, and that's why they aren't dealing with it aggressively. But I agree that we're heading towards a profound change in technology and business models. From dave at immunityinc.com Mon Apr 7 17:16:18 2008 From: dave at immunityinc.com (Dave Aitel) Date: Mon, 07 Apr 2008 17:16:18 -0400 Subject: [Dailydave] Exploitation has a heartbeat. Message-ID: <47FA8F22.1060609@immunityinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Every exploit is a story. Sometimes this story gets quite involved and has a tempo - Bas explained his current heap overflow to me today. It takes a few days, you find the trick, and then it's just typing. Nico's heap overflow explanations are often much more...lengthy. I still think there's a market out there for a book that goes beyond the basics. In any case, for people who themselves want to go beyond the basics, Immunity Debugger now has a free "looking for a job" portion. Go here to submit: http://debugger.immunityinc.com/hireahacker.html And if you're at RSA, go find Justine, Kostya or Sinan and say hi! :> - -dave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH+o8htehAhL0gheoRAt6bAJoC/zNNmG6oOBXjORknXir8A4/rmwCfc1lp PgjK5eWLbSkbGL8BEl7VZ9s= =Kee9 -----END PGP SIGNATURE----- From dave at immunityinc.com Tue Apr 8 10:18:17 2008 From: dave at immunityinc.com (Dave Aitel) Date: Tue, 08 Apr 2008 10:18:17 -0400 Subject: [Dailydave] Google Apps Engine Message-ID: <47FB7EA9.2000503@immunityinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Google has some fairly ambitious plans for their hosted application development as far as security is concerned. For example, here is a Python shell on a Google box: http://shell.appspot.com/ . How awesome is that? Neel Mehta must be working overtime to secure all of this. I hope they're running grsec on those boxes. :> I can think of a lot of neat ways to use the Google API. A few lines of code in SPIKE Proxy which hooks it up to the Google.urlfetch() and you have a web proxy that bounces through any machine Google decides to push you out of. Their database looks pretty useful as well for the kinds of large forms of data security tools generate. So now we know what Guido has been up to! :> - -dave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH+36ptehAhL0gheoRAhNTAKCDEvbCjJ+ZTj0GmWjgLOhAx5p5aACeJHSP 5qra6Py3AyNeNVzvsTfokfA= =nCVQ -----END PGP SIGNATURE----- From jf at danglingpointers.net Tue Apr 8 18:52:30 2008 From: jf at danglingpointers.net (jf) Date: Tue, 8 Apr 2008 22:52:30 +0000 (UTC) Subject: [Dailydave] Google Apps Engine In-Reply-To: <47FB7EA9.2000503@immunityinc.com> References: <47FB7EA9.2000503@immunityinc.com> Message-ID: cFunny you should mention this, I've been sitting here all night documenting all of these stupid stupid bugs in Python. On a side note, if you segfault this app it starts returning 403 over quota errors :/ PyString_FromStringAndSize() FTW! >>> __import__('zlib').decompressobj().flush(-24) 500 Server Error
Google    
Error
 

Server Error

The server encountered an error and could not complete your request.

If the problem persists, please report your problem and mention this error message and the query that caused it.

From jeremy at austin.ibm.com Tue Apr 8 11:26:49 2008 From: jeremy at austin.ibm.com (Jeremy Kelley) Date: Tue, 8 Apr 2008 10:26:49 -0500 Subject: [Dailydave] Google Apps Engine In-Reply-To: <47FB7EA9.2000503@immunityinc.com> References: <47FB7EA9.2000503@immunityinc.com> Message-ID: <20080408152649.GA797@ark.ibm.com> Quoting Dave Aitel (dave at immunityinc.com): > Google has some fairly ambitious plans for their hosted application > development as far as security is concerned. For example, here is a > Python shell on a Google box: http://shell.appspot.com/ . How awesome is > that? Neel Mehta must be working overtime to secure all of this. I hope > they're running grsec on those boxes. :> > > I can think of a lot of neat ways to use the Google API. A few lines of > code in SPIKE Proxy which hooks it up to the Google.urlfetch() and you > have a web proxy that bounces through any machine Google decides to push > you out of. Their database looks pretty useful as well for the kinds of > large forms of data security tools generate. > > So now we know what Guido has been up to! :> I got involved in one of those irc discussions "what if ..." and went and looked at how hard it'd be to clean up the std library of any functions that actually touched the filesystem and handled process creation. It wouldn't be difficult, but you'd have to also add some hooks to handle manipulation of sys.path to avoid pulling in other libs and files via imports. For the most part, a standard compiled interpreter could be sanitized quite easily just by removing many of the stdlibs. There are certain calls that come to mind like open() that are builtin and C that I believe would be a bit harder to cleanup, though. Even those could easily be sanitized by just some fun with function pointers. >>> open=lambda *x: "no" >>> open('/etc/passwd') 'no' I can't get to the shell right now, as apparently, your email to the list has sparked a bit of traffic. This Google App Engine application is temporarily over its serving quota. Please try again later. I wonder if this is what they're doing to lock it down, or if they truly sandboxed the whole thing in some secure way. -jeremy -- Jeremy Kelley Sr. Threat Analyst gpg 1024D/E0DF8B2D 4BC3 B8B5 5B42 CC8E B6A9 2E85 32D3 C51C E0DF 8B2D That's the problem with science. You've got a bunch of empiricists trying to describe things of unimaginable wonder. -Bill Watterson From kbaumgartner at pctools.com Tue Apr 8 12:12:47 2008 From: kbaumgartner at pctools.com (Kurt Baumgartner) Date: Tue, 8 Apr 2008 10:12:47 -0600 Subject: [Dailydave] Security FAIL. In-Reply-To: <871w5k6mhz.fsf@mid.deneb.enyo.de> References: <47F66983.4020700@immunityinc.com> <871w5k6mhz.fsf@mid.deneb.enyo.de> Message-ID: >There is a general insistence in the AV industry to test only malware >which is a few weeks old. Not true. Often, samples that the vendors miss are months old. It's very unfortunate that the misses occur even against sets from the "Wild List". The AV vendors, testers, journalists, academics, and other security players are working on it this year -- www.amtso.org. >I'm not sure if it's a problem for the AV companies, though. Their >brands are quite strong, and the policies that guarantee them a steady >revenue stream are well-enshrined industry-wide. Certainly it's not >going to affect them in the current CEO cycle, and that's why they >aren't dealing with it aggressively. May be true for some, but not true for all AV companies. While there hasn't been a seismic shift in the industry just yet, multiple AV companies are very interested in improving effectiveness in their products and acting on it (Microsoft included). > we're heading towards a profound change in technology and business models. It's about time. Kurt From jf at danglingpointers.net Tue Apr 8 20:08:47 2008 From: jf at danglingpointers.net (jf) Date: Wed, 9 Apr 2008 00:08:47 +0000 (UTC) Subject: [Dailydave] Google Apps Engine In-Reply-To: <20080408152649.GA797@ark.ibm.com> References: <47FB7EA9.2000503@immunityinc.com> <20080408152649.GA797@ark.ibm.com> Message-ID: > I can't get to the shell right now, as apparently, your email to the > list has sparked a bit of traffic. > > This Google App Engine application is temporarily over its serving > quota. Please try again later. Actually, thats what it appears to do on segfault. I, um, mentioned it in irc and it hasn't really been working well since. From dave at immunityinc.com Tue Apr 8 15:51:08 2008 From: dave at immunityinc.com (Dave Aitel) Date: Tue, 08 Apr 2008 15:51:08 -0400 Subject: [Dailydave] Movies, ponds, and MS08_025. Message-ID: <47FBCCAC.9040608@immunityinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Movies: http://www.immunityinc.com/documentation/ms08_025.html Ah, the fun of a picture that changes over time. I guess the point with that little flash screencast is: It's not "exploit Wednesday"[1] anymore. Everyone's instinct is to attack the most secure platform - for example, when a patch only affects IE6, people think "whatever", but then I get emails from people who's entire large government organizations are standardized on IE6. So IE6 bugs ARE important, which is nice because it's a much deeper pond to fish in. - -dave [1] I really hate that term anyways. It implies that exploits derive from patches, instead of the other way around. It sounds like something Jeff Jones would come up with. :> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH+8ystehAhL0gheoRAgARAJwJDIpVORVxUbmHfDODWxUORhAvUwCfQqf+ CSlfJY9H2w9MlKhOevXkfsY= =fdzR -----END PGP SIGNATURE----- From smooge at gmail.com Tue Apr 8 16:53:25 2008 From: smooge at gmail.com (Stephen John Smoogen) Date: Tue, 8 Apr 2008 14:53:25 -0600 Subject: [Dailydave] Movies, ponds, and MS08_025. In-Reply-To: <47FBCCAC.9040608@immunityinc.com> References: <47FBCCAC.9040608@immunityinc.com> Message-ID: <80d7e4090804081353icd32588j73c8b0064f17fc43@mail.gmail.com> On Tue, Apr 8, 2008 at 1:51 PM, Dave Aitel wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Movies: http://www.immunityinc.com/documentation/ms08_025.html > > Ah, the fun of a picture that changes over time. I guess the point with > that little flash screencast is: It's not "exploit Wednesday"[1] anymore. > > Everyone's instinct is to attack the most secure platform - for example, > when a patch only affects IE6, people think "whatever", but then I get > emails from people who's entire large government organizations are > standardized on IE6. So IE6 bugs ARE important, which is nice because > it's a much deeper pond to fish in. > > - -dave > > [1] I really hate that term anyways. It implies that exploits derive > from patches, instead of the other way around. It sounds like something > Jeff Jones would come up with. :> Well there are a bunch of people who only look at what is patched and then use it for their own feeding fests. They are also the ones usually caught/stopped/etc and so it makes it look more like exploits come from patches versus the other. The smart guys who rarely get caught or attention have been using the vulnerability for a lot longer. Yes, it is quite common that IE6 is in heavy usage.. its one of the reasons I saw Vista being delayed at a site. All the business tools only work with IE6 and so that is what everyone uses. Some places are trying to limit attack vectors by putting IE6 and god awful old versions of Word in VM's that the users connect to. However, how secure or useful that is.. I am not sure. As you said, the flashy get the flag in Vista etc is the eye candy that gets reporters, blogs, etc attention. The finding an exploit in a 5-7 year old version of Word gets poo-poo'd but since 80% of your 'moneyed' victims are still using it.. its what you want (plus you don't grab the attention that might get you busted sooner.) -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From dave at immunityinc.com Wed Apr 9 10:36:47 2008 From: dave at immunityinc.com (Dave Aitel) Date: Wed, 09 Apr 2008 10:36:47 -0400 Subject: [Dailydave] End Software Patents Message-ID: <47FCD47F.6000004@immunityinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Software Patents are a horrible thing. They're bad for big companies, they're bad for small companies, and they're bad for society in general. The Free Software Foundation is helping end them. Vote with your money: https://www.fsf.org/donate/directed-donations/esp?amount=500 - -dave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH/NR/tehAhL0gheoRAsuWAJ98W+6IScYJS0MFsx2yJD7npctDIgCfXMrs yTf7DvTIovSyOozuusrd5lw= =tnFJ -----END PGP SIGNATURE----- From dr at kyx.net Thu Apr 10 17:30:06 2008 From: dr at kyx.net (Dragos Ruiu) Date: Thu, 10 Apr 2008 14:30:06 -0700 Subject: [Dailydave] EUSecWest CFP Closes April 14th (conf May 21/22 2008) Message-ID: <200804101430.06582.dr@kyx.net> (We've moved the conference this year to the a club in Leicester Square in the heart of London and SoHo. We'll be putting speakers up across the square at the Radisson Edwardian Hampshire, but there are lots of hotels in the region there in the center of London for those who want to attend (the venue is physically on top of a tube station on Circle line so easy to get to). Registration is now open and we hope to have the Dojo registrations on-line by this weekend. The conference is on Wednesday/Thursday, which leaves Friday to fly to Berlin for those going to ph-n. cheers, --dr) EUSecWest CALL FOR PAPERS LONDON, U.K. -- The second annual EUSecWest applied technical security conference - where the eminent figures in the international security industry will get together share best practices and technology - will be held in downtown London at the Sound club in Leicester Square on May 21/22 2008. The most significant new discoveries about computer network hack attacks and defenses, commercial security solutions, and pragmatic real world security experience will be presented in a series of informative tutorials. The EUSecWest meeting provides international researchers a relaxed, comfortable environment to learn from informative tutorials on key developments in security technology, and collaborate and socialize with their peers in one of the world's most central cities. The EUSecWest conference will also feature the availability of the Security Masters Dojo expert network security sensei instructors, and their advanced, and intermediate, hands-on training courses - featuring small class sizes and practical application excercises to maximize information transfer. We would like to announce the opportunity to submit papers, lightning talk proposals for selection by the EUSecWest technical review committee. Please make your paper proposal submissions before April 14th, 2008. 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 secwest08 [at] eusecwest.com . Only slides will be needed for the May paper deadline, full text does not have to be submitted - but will be accepted if available. The EUSecWest 2008 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 new 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. Optionally, any samples of prepared material or outlines ready. 8. Will you have full text available or only slides? 9. Please list any other publications or conferences where this material has been or will be published/submitted. Please include the plain text version of this information in your email as well as any file, pdf, sxw, ppt, or html attachments. Please forward the above information to secwest08 [at] eusecwest.com to be considered for placement on the speaker roster, have your lightning talk scheduled. -- World Security Pros. Cutting Edge Training, Tools, and Techniques London, U.K. May 21/22 - 2008 http://eusecwest.com pgpkey http://dragos.com/ kyxpgp From toby00 at gmail.com Thu Apr 10 17:39:54 2008 From: toby00 at gmail.com (toby) Date: Thu, 10 Apr 2008 14:39:54 -0700 Subject: [Dailydave] Fwd: [vizSEC] VizSEC 2008 Workshop on Visualization for Cyber Security In-Reply-To: References: Message-ID: <747811030804101439j3cd8da11o11e0a90e87525f0c@mail.gmail.com> ---------- Forwarded message ---------- From: John Goodall Date: Thu, Apr 10, 2008 at 12:24 PM Subject: [vizSEC] VizSEC 2008 Workshop on Visualization for Cyber Security To: info at lists.vizsec.org Cc: John Goodall The full and short paper deadline for VizSec has been extended. Proceedings will be published by Springer's Lecture Notes in Computer Science. The Keynote speaker at VizSec will be Ben Shneiderman, speaking on the topic Information Forensics: Harnessing visualization to support discovery. VizSEC 2008 Workshop on Visualization for Cyber Security http://vizsec.org/workshop2008/ September 15, 2008 / Cambridge, MA USA In conjunction with RAID 2008 The 5th International Workshop on Visualization for Cyber Security will provide a forum for new research in visualization for computer security. We are pleased to be holding this year's meeting in conjunction with the 11th International Symposium on Recent Advances in Intrusion Detection. The VizSec Workshop will be held at MIT in Cambridge, Massachusetts USA on Monday, September 15, 2008. The Keynote this year will be given by Ben Shneiderman on the topic Information Forensics: Harnessing visualization to support discovery As a result of previous VizSec workshops, we have seen both the application of existing visualization techniques to security problems and the development of novel security visualization approaches. However, VizSec research has focused on helping human analysts to detect anomalies and patterns, particularly in computer network defense. Other communities, led by researchers from the RAID Symposia, have researched automated methods for detecting anomalies and malicious activity. The theme for this year's workshop, which will be held in conjunction with RAID 2008, will be on bridging the gap between visualization and automation, such as leveraging the power of visualization to create rules for intrusion detection and defense systems. We encourage VizSec participants to stay for the RAID Symposium and RAID participants to come a day early to participate in VizSec. There will be a discount for joint registration. We also solicit papers that report results on visualization techniques and systems in solving all aspects of cyber security problems, including: * Visualization of Internet routing * Visualization of packet traces and network flows * Visualization of intrusion detection alerts * Visualization of attack tracks * Visualization of security vulnerabilities * Visualization of attack paths * Visualization of application processes * Visualization for forensic analysis * Visualization for correlating events * Visualization for computer network defense training * Visualization for offensive information operations * Visualization for building rules * Visualization for feature selection * Visualization for detecting anomalous activity * Deployment and field testing of VizSec systems * Evaluation and user testing of VizSec systems * User and design requirements for VizSec systems * Lessons learned from development and deployment of VizSec systems All submitted papers will be peer-reviewed. Full and short papers will be published by Springer Lecture Notes in Computer Science (LNCS) in the VizSec 2008 Proceedings. Poster and Demo abstracts will be made available on the VizSec web site. Submissions should list all authors and their affiliations; in case of multiple authors, the contact author must be indicated (anonymized submissions are not required). For accepted papers, at least one of the authors must attend the conference to present the work. Submissions must be in PDF format. All submissions should include an abstract, keywords, references, and high resolution, color images. Submissions must not substantially duplicate work that any of the authors has published elsewhere or has submitted in parallel to a journal or to any other conference or workshop with proceedings. Simultaneous submission of the same work to multiple venues, submission of previously published work, and plagiarism constitute dishonesty or fraud. VizSec, like other scientific and technical conferences and journals, prohibits these practices and may, on the recommendation of the program chair, take action against authors who have committed them. Further questions on the submission process may be sent to the program chair. Deadlines April 21, 2008 : Deadline for full paper submission May 19, 2008 : Deadline for short paper submissions July 18, 2008 : Deadline for poster and demo abstracts Full Papers Full papers should present mature research results. Accepted papers will be presented and included in the VizSec 2008 proceedings. Papers must include an abstract and a list of keywords and can be up to 18 pages in total length, including the bibliography and appendices. Short Papers Short papers can be used to present less mature research results than full papers, or late-breaking results. Accepted short papers will be presented and included in the VizSec 2008 proceedings. Short papers must include an abstract and a list of keywords and can be up to 8 pages in total length, including the bibliography and appendices. Posters Posters can be used to describe work in progress or updates to previously published VizSec research or R&D. Poster submissions should consist of a 2 page abstract. Poster will be presented at the VizSec/RAID reception. Abstracts will be made available on the web site. Demos Demonstrations can be used to show new or updated development efforts. Demo submissions should consist of a 2 page abstract. Demonstrations will take place at the VizSec/RAID reception. (You will need to bring a laptop for demos.) Abstracts will be made available on the web site. Formatting Instructions All accepted, camera-ready manuscripts must be submitted using the LaTeX2e (strongly preferred) or Word templates provided by Springer for LNCS 'Proceedings and Other Multiauthor Volumes.' http://www.springer.com/computer/lncs?SGWID=0-164-7-72376-0 Submission Instructions Please submit PDF papers using the EasyChair workshop site: http://www.easychair.org/conferences/?conf=vizSEC08 VizSec 2008 is sponsored by: NSA's National Information Assurance Research Laboratory (NIARL) Microsoft CA Labs Applied Visions http://vizsec.org/workshop2008/ -- john goodall, phd . JohnG at SecureDecisions.avi.com 518.248.8195 (mobile) . 631.754.4920 (office) Secure Decisions division of Applied Visions Inc. http://securedecisions.com . http://vizsec.org _______________________________________________ Info mailing list Info at lists.vizsec.org http://lists.vizsec.org/mailman/listinfo/info_lists.vizsec.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20080410/b5e36443/attachment-0001.htm From lboehne at damogran.de Fri Apr 11 10:33:14 2008 From: lboehne at damogran.de (Lutz =?iso-8859-1?Q?B=F6hne?=) Date: Fri, 11 Apr 2008 16:33:14 +0200 Subject: [Dailydave] Google Apps Engine In-Reply-To: <20080408152649.GA797@ark.ibm.com> References: <47FB7EA9.2000503@immunityinc.com> <20080408152649.GA797@ark.ibm.com> Message-ID: <20080411143314.GA25341@localhost> > Even those could easily be sanitized by just some fun with function > pointers. > > >>> open=lambda *x: "no" > >>> open('/etc/passwd') > 'no' Unless there are other ways to find these functions: >>> __builtins__.__dict__["open"]( '/etc/passwd') or even: >>> open=lambda *x: "no" >>> open('/etc/passwd') 'no' >>> del open >>> open('/etc/passwd') Python is fun, there are so many ways to have it do what you want ;) It might be possible to remove these functions like this: >>> del __builtins__.__dict__["open"] >>> open('/etc/passwd') Traceback (most recent call last): File "", line 1, in NameError: name 'open' is not defined [...] But i don't know whether that'd get rid of all problems. Best regards, Lutz -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: Digital signature Url : http://lists.immunitysec.com/pipermail/dailydave/attachments/20080411/bfcac9f5/attachment.pgp From dave at immunityinc.com Fri Apr 11 11:19:30 2008 From: dave at immunityinc.com (Dave Aitel) Date: Fri, 11 Apr 2008 11:19:30 -0400 Subject: [Dailydave] Samba, Google, and The Audacity of Hope Message-ID: <47FF8182.6090205@immunityinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I think launching the Google Application Engine is pretty much an audacity of hope kind of event - the zlib bug in Python on the day it came out is just the tip of the tip of the iceberg as far as that sort of bug goes. Did they really think you can sandbox someone inside cPython by removing local file access and the socket module? Perhaps Guido sat down and audited it for bugs and just missed one. One thing I'm learning from that is that "auditing your code" is not a security solution. It's a stop-gap that is hugely expensive and sometimes a good learning solution. Its goal is to help you produce automated solutions to find similar bugs, and guide your technology decisions to more secure platforms. Because what DOES work is moving to a more secure platform. In Google's case, IronPython on Mono is probably their best solution. But there are lots of other places this is important that people ignore too. For example, you can own your Asus Eee PC out of the box with Samba. I understand they need to have CIFS support, and Samba is considered the top of the line. But Eee PC customers don't need all the features of Samba. They just need something to mount drives and share files. There's lots of Python/Ruby/Perl stacks that can do all these things and don't have buffer overflows. Also, Samba is a nightmare to configure, so picking another stack would have lots of side benefits. It's not like there won't be another overflow in Samba someday soon. Installing Samba exposed to the world on your consumer-linux without a nice way to update it is very "hopeful". If someone wants to build a nice GUI and Ubuntu package based on the CANVAS SMBServer/client code, we'd donate that code to GPLv3. - -dave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH/4GBtehAhL0gheoRAvyEAJ4zDa54oat1XcLtV/47m862cOK/oQCeLWmB gRbBjDqIoLF73jKmpykH8p0= =wllt -----END PGP SIGNATURE----- From jeremy at austin.ibm.com Fri Apr 11 13:06:13 2008 From: jeremy at austin.ibm.com (Jeremy Kelley) Date: Fri, 11 Apr 2008 12:06:13 -0500 Subject: [Dailydave] Google Apps Engine In-Reply-To: <20080411143314.GA25341@localhost> References: <47FB7EA9.2000503@immunityinc.com> <20080408152649.GA797@ark.ibm.com> <20080411143314.GA25341@localhost> Message-ID: <20080411170613.GA713@ark.ibm.com> Quoting Lutz B?hne (lboehne at damogran.de): > Python is fun, there are so many ways to have it do what you want ;) > > It might be possible to remove these functions like this: > > >>> del __builtins__.__dict__["open"] > >>> open('/etc/passwd') > Traceback (most recent call last): > File "", line 1, in > NameError: name 'open' is not defined > [...] > > But i don't know whether that'd get rid of all problems. doh! Good catch on the builtins. I should have looked further for that example. I did see today that Guido was one of the lead guys on the google appserver codebase. I'd be interested in hearing from him on ways they may be preparing to offer a sanitized environment. -j -- Jeremy Kelley Sr. Threat Analyst gpg 1024D/E0DF8B2D 4BC3 B8B5 5B42 CC8E B6A9 2E85 32D3 C51C E0DF 8B2D That's the problem with science. You've got a bunch of empiricists trying to describe things of unimaginable wonder. -Bill Watterson From jf at danglingpointers.net Fri Apr 11 20:41:18 2008 From: jf at danglingpointers.net (jf) Date: Sat, 12 Apr 2008 00:41:18 +0000 (UTC) Subject: [Dailydave] Samba, Google, and The Audacity of Hope In-Reply-To: <47FF8182.6090205@immunityinc.com> References: <47FF8182.6090205@immunityinc.com> Message-ID: > I think launching the Google Application Engine is pretty much an > audacity of hope kind of event - the zlib bug in Python on the day it > came out is just the tip of the tip of the iceberg as far as that sort > of bug goes. Did they really think you can sandbox someone inside > cPython by removing local file access and the socket module? Perhaps > Guido sat down and audited it for bugs and just missed one. The thing is, people don't seem to recognize the interpreter itself as attack surface for some reason-- we seem to neglect to recognize that these languages are just C programs, complete with all of its flaws. They come with their own metadata, their own callstacks, et cetera and all of the protections we currently have in place are designed to stop me from attacking the processors metadata-- if I find an overflow in Python and attack a PyFrameObject and return into Python bytecode, does your NX bit still help? How effective is ASLR? et cetera. When you have a heap overflow in Python, you can potentially hit one of those frame objects- and with some luck you can take advantage of the 'zombie frame', which is basically just a cached frame with some assumptions made. Or perhaps you can cause an in-language exception and hit the right frame object, then you can take advantage of the exception handling mechanisms in an environment that doesn't have a /SafeSEH option. There's lots of options, and no one is looking at this type of stuff-- well other than Stephan Esser, and thats (?all?/?mostly?/?whatever?) in PHP. What we need to understand is that these scripts can be viewed as an interface to a C application, that for some reason we expect that the same people who can't write a mail server, or a web server, or a file server can suddenly develop an entire environment/language that is bug free, and this is just utterly absurd. This isn't a testament to the quality of developers working on Python, its a testament to the complexity of developing software. The Python guys have actually been great, They patched the bug the same day it was reported (shortly after sending off the email here I went and reported it and hours after that a fix was checked into CVS). They were polite and their concern appears genuine and thats always a good sign. Guido contacted me off list wanting to know if there was anything he could do to help me help him. Python, like any substantial program has it's bugs, but if you look at the code it's actually pretty simple and very straight forward-- I understood the callstack in hours, whereas as I work through the same thing in PERL I begin to agree with a friend who is of the opinion that it is a code base that wasn't written but instead found on a crashed UFO (yeah it is that weird...seriously). If people are interested in this stuff, I'll be speaking about it at ph-neutral, and pending the responses of other conferences perhaps there as well. (and thats why the advisory didnt delve into exploitation) From dave.aitel at gmail.com Fri Apr 11 18:49:34 2008 From: dave.aitel at gmail.com (Dave Aitel) Date: Fri, 11 Apr 2008 18:49:34 -0400 Subject: [Dailydave] Papers to be read immediately by Mark Dowd+=1 Message-ID: http://documents.iss.net/whitepapers/IBM_X-Force_WP_final.pdf Word up to duke who once, long ago, was just another cool cat trying to learn X.25 on the Internet Relay Chat. -dave -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20080411/e492c516/attachment.htm From travis+ml-dailydave at subspacefield.org Fri Apr 11 19:53:18 2008 From: travis+ml-dailydave at subspacefield.org (travis+ml-dailydave at subspacefield.org) Date: Fri, 11 Apr 2008 18:53:18 -0500 Subject: [Dailydave] security concepts ebook published Message-ID: <20080411235318.GL13338@subspacefield.org> I'm working on a book I thought some of you might enjoy: http://www.subspacefield.org/security/security_concepts.html http://www.subspacefield.org/security/security_concepts.pdf The parts I'm most proud of are the security principles, ch 24. I'm really busy of late, but do appreciate suggestions. I enjoy discussing these things, and though it may take a while, I do carefully save updates for the next time I have several hours free to do a major edit. -- https://www.subspacefield.org/~travis/ My password is easy to remember; it's the digits of Pi. All of them. If you are a spammer, please email john at subspacefield.org to get blacklisted. From dominique.brezinski at gmail.com Fri Apr 11 20:44:18 2008 From: dominique.brezinski at gmail.com (dominique.brezinski at gmail.com) Date: Sat, 12 Apr 2008 00:44:18 +0000 Subject: [Dailydave] Samba, Google, and The Audacity of Hope In-Reply-To: References: <47FF8182.6090205@immunityinc.com> Message-ID: <1987054379-1207960866-cardhu_decombobulator_blackberry.rim.net-1336066180-@bxe123.bisx.prod.on.blackberry> Sorry for the top post...too difficult to quote from a blackberry. I gave a presentation at black hat Tokyo a few years ago on security of interpreted languages and the interpreter as attack surface that has to be taken into account for certain applications. I do a lot more ruby stuff than python, so I took a quick look, as did John McDonald, and we found a few int overflows in the first few minutes. It seems that the issue of interpreter robustness is just about to break into the mainstream consciousness of security folks, but to some degree these issues have been in small-scale discussions for years now. It sounds like the python guys are more responsive and open than the ruby core community. I had a lot of problems trying to discuss the underlying issues with core ruby developers. They were quick to try to shut me up and out of their little world. I hope that changes in the future. Cheers, Dom Sent via BlackBerry from T-Mobile -----Original Message----- From: jf Date: Sat, 12 Apr 2008 00:41:18 To:Dave Aitel Cc:dailydave at lists.immunityinc.com Subject: Re: [Dailydave] Samba, Google, and The Audacity of Hope > I think launching the Google Application Engine is pretty much an > audacity of hope kind of event - the zlib bug in Python on the day it > came out is just the tip of the tip of the iceberg as far as that sort > of bug goes. Did they really think you can sandbox someone inside > cPython by removing local file access and the socket module? Perhaps > Guido sat down and audited it for bugs and just missed one. The thing is, people don't seem to recognize the interpreter itself as attack surface for some reason-- we seem to neglect to recognize that these languages are just C programs, complete with all of its flaws. They come with their own metadata, their own callstacks, et cetera and all of the protections we currently have in place are designed to stop me from attacking the processors metadata-- if I find an overflow in Python and attack a PyFrameObject and return into Python bytecode, does your NX bit still help? How effective is ASLR? et cetera. When you have a heap overflow in Python, you can potentially hit one of those frame objects- and with some luck you can take advantage of the 'zombie frame', which is basically just a cached frame with some assumptions made. Or perhaps you can cause an in-language exception and hit the right frame object, then you can take advantage of the exception handling mechanisms in an environment that doesn't have a /SafeSEH option. There's lots of options, and no one is looking at this type of stuff-- well other than Stephan Esser, and thats (?all?/?mostly?/?whatever?) in PHP. What we need to understand is that these scripts can be viewed as an interface to a C application, that for some reason we expect that the same people who can't write a mail server, or a web server, or a file server can suddenly develop an entire environment/language that is bug free, and this is just utterly absurd. This isn't a testament to the quality of developers working on Python, its a testament to the complexity of developing software. The Python guys have actually been great, They patched the bug the same day it was reported (shortly after sending off the email here I went and reported it and hours after that a fix was checked into CVS). They were polite and their concern appears genuine and thats always a good sign. Guido contacted me off list wanting to know if there was anything he could do to help me help him. Python, like any substantial program has it's bugs, but if you look at the code it's actually pretty simple and very straight forward-- I understood the callstack in hours, whereas as I work through the same thing in PERL I begin to agree with a friend who is of the opinion that it is a code base that wasn't written but instead found on a crashed UFO (yeah it is that weird...seriously). If people are interested in this stuff, I'll be speaking about it at ph-neutral, and pending the responses of other conferences perhaps there as well. (and thats why the advisory didnt delve into exploitation) _______________________________________________ Dailydave mailing list Dailydave at lists.immunitysec.com http://lists.immunitysec.com/mailman/listinfo/dailydave From dtangent at defcon.org Fri Apr 11 20:54:47 2008 From: dtangent at defcon.org (The Dark Tangent) Date: Fri, 11 Apr 2008 17:54:47 -0700 Subject: [Dailydave] DEF CON 16 Retro Announcement! Back to Bang! Message-ID: <001301c89c37$d4af6d20$7e0e4760$@org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 With the passing of "The Jackal" I was looking in the DEF CON archives for an old picture of him at the first DEF CON, and came across the first con announcement. To commemorate both I decided to announce DEF CON 16 in the same style. How 'bout those InterNets? - ---------------------------------------------------------------------------- - -- D E F C O N 16 C O N V E N T I O N D E F C O N 16 C O N V E N T I O N D E F C O N 16 C O N V E N T I O N D E F C O N 16 C O N V E N T I O N >> READ AND DISTRIBUTE AND READ AND DISTRIBUTE AND READ AND DISTRIBUTE << Announcement: 4/11/2008 We are proud to announce the 16th annual Def Con. If you are at all familiar with any of the previous Cons, then you will have a good idea of what DEF CON will be like. If you don't have any experience with Cons, they are an event on the order of a pilgrimage to Mecca for the underground. They are a mind-blowing orgy of information exchange, viewpoints, speeches, education, enlightenment... And most of all sheer, unchecked PARTYING. It is an event that you must experience at least once in your lifetime. The partying aside, it is a wonderful opportunity to met some of the luminaries of the underground computer scene and those that shape its destiny - the researchers, hackers, libertarians, and info-rebels of various kinds. Most of all, there will be plenty of open-ended discussion on security, networks, and other topics as well as what TIME magazine calls the "Cyberpunk Movement". Las Vegas is, as you might have guessed, a great choice for the Con. Gambling, loads of hotels and facilities, cheap air fare and room rates. It's also in the West Coast making it more available to a different crowd than the former Cons have been. Your foray into the scene and your life will be forever incomplete if by some chance you miss out on DEF CON 16. Plan to be there! WHO: You know who you are. WHAT: Super Hacker Party Fest, with Speakers, contests, even live music. WHERE: Las Vegas, Nevada WHEN: August 8 - 10 (Fri, Sat, Sun) 2008 WHY: To meet all the other people out there you've been talking to for months and months, and get some solid information instead of rumors. DESCRIPTION: So you're bored, and have never gone to a convention? You want to meet all the other members of the so called 'computer underground'? You've been calling BBS systems for a long time now, and you definitely have been interacting on the national networks. You've bullshitted with the best, and now it's time to meet them in Vegas! For me I've been networking for years, and now I'll get a chance to meet everyone in the flesh. Get together with a group of your friends and make the journey. We cordially invite all hackers, phreaks, techno-rats, programmers, writers, activists, lawyers, philosophers, politicians, security officials, cyberpunks and all network sysops and users to attend. DEF CON 16 will be over the weekend in the middle of down town Las Vegas at the Riviera Hotel. Why Las Vegas? Las Vegas is the place to do it. Cheap food, alcohol, lots of entertainment and, like us, it never sleeps. We will have the entire convention meeting space, so no sharing with the 'norms' this year. Events and speakers will be there to provide distraction and some actual information and experiences from this loosely knit community from lock picking, robot wars, the Black & White ball to the mystery box challenge and the premier Capture the Flag contest! See the site for an ever growing list of happenings. This is an initial announcement. It is meant only to alert you to the time, dates and location of the convention. Future announcements will inform you about specific speakers and events. An information pack is off of the internet at https://www.defcon.org/ The IP# is 216.231.40.180 Information updates will be posted there in the future as well as updated speaker lists. CALL FOR PAPERS OPEN! SPEAKERS: We want to solicit speakers from all aspects of the computer underground and associated culture (Law, Media, Software Companies, Cracking Groups, Hacking Groups, Magazine Editors, Etc.) If you or anyone you know of is interested in speaking on a self selected topic, please submit a CFP. - From hacking your car, your brain, and CIA sculptures to hacking the vote, Bluetooth, and DNS hacks. We group presentations by subject and come up with topic areas, or "clusters" of interest. It worked out so well in the past we are doing it again. What are we looking for then, if we don't have tracks? Were looking for the presentation that you've never seen before and have always wanted to see. We are looking for the presentation that the attendees wouldn't ask for, but blows their minds when they see it. We want strange demos of Personal GPS jammers (Lady Ada?), RFID zappers, and HERF madness. Got a MITM attack against cell phones or a way to duplicate fingerprints? (CCC?) We want to see it! GET INVOLVED: There are many contests and groups to get involved with. If you don't know anyone don't phear, get involved. Join the forums, read up on the contests, plan a party, do something! FOR MORE INFORMATION: For initial comments, requests for more information, information about speaking at the event, or maps to the section where prostitution is legal outside Las Vegas (Just Kidding) Contact The Dark Tangent by leaving me mail at: dtangent at defcon.org on the InterNet. Future information updates will pertain to the speaking agenda. - ---------------------------------------------------------------------------- - -- Web Site https://www.defcon.org/ Submit a CFP https://www.defcon.org/html/defcon-16/dc-16-cfp-form.html Forums - Discuss and follow all the pre-conference planning https://forum.defcon.org/ Future Announcements in RSS format https://www.defcon.org/defconrss.xml The Jackal, holding the radio right behind Aleph One https://www.defcon.org/images/graphics/PICTURES/defcar1.jpg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.7.0 (Build 1012) Charset: us-ascii wsBVAwUBSAAIqg6+AoIwjTCUAQgOIgf+Oly3L51HgTkwOxm/ZEIE1qIuvPXbISYN Ml1f7RJ4aedKounTFG6wbIRumBiDfW8toDGcPeSZMWdFdlwsWOaVrzkqgmz/AlZ/ RGkIdS2pWWLx4adP5dgC0BM/8Wzxto0OmTLoRfE1OdSdkqPp+I5p+DC/f4N7+kga BgUjRZxwSDS/pngxjORZGarWW+BcCj6XMbL5Ox1qO8dWWk6Z9iLxrk8ixLLtUih7 2cfl+RHlBMGLt9PsMcOpbU+qfFhKoMZ8gzHHAS8WgB2o6Y6u2OKcDEGSj35ztXiS 43Rpbe0/Yk5sK3ySDK7Gsw6mN3AO7qh794zg5M2Lg9s9laiX5ULDgg== =EfUc -----END PGP SIGNATURE----- From mark.dowd at gmail.com Fri Apr 11 21:18:01 2008 From: mark.dowd at gmail.com (Mark Dowd) Date: Sat, 12 Apr 2008 11:18:01 +1000 Subject: [Dailydave] Papers to be read immediately by Mark Dowd+=1 In-Reply-To: References: Message-ID: <816ef1ca0804111818s61dd8d51mc53d80718b49ac5f@mail.gmail.com> Hey there, I was actually going to post about this myself, but OK :). For anyone interested, Adobe recently released a patch for Flash Player that addressed several vulnerabilities, one of which I discovered. I found a pretty interesting way to get reliable execution by leveraging the mechanics of the ActionScript Virtual Machine (AVM). Essentially the technique revolves around being able to run unverified ActionScript, which is decidedly bad as it turns out. As Dave already pointed out, the document is availables at http://documents.iss.net/whitepapers/IBM_X-Force_WP_final.pdf. Enjoy! -mark PS. I still don't know anything about X.25! On Sat, Apr 12, 2008 at 8:49 AM, Dave Aitel wrote: > http://documents.iss.net/whitepapers/IBM_X-Force_WP_final.pdf > > Word up to duke who once, long ago, was just another cool cat trying to > learn X.25 on the Internet Relay Chat. > > -dave > > > _______________________________________________ > 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/20080412/25695ccc/attachment.htm From makosoft at googlemail.com Sat Apr 12 04:09:09 2008 From: makosoft at googlemail.com (Aidan Thornton) Date: Sat, 12 Apr 2008 09:09:09 +0100 Subject: [Dailydave] Google Apps Engine In-Reply-To: <20080411143314.GA25341@localhost> References: <47FB7EA9.2000503@immunityinc.com> <20080408152649.GA797@ark.ibm.com> <20080411143314.GA25341@localhost> Message-ID: On 4/11/08, Lutz B?hne wrote: > > Even those could easily be sanitized by just some fun with function > > pointers. > > > > >>> open=lambda *x: "no" > > >>> open('/etc/passwd') > > 'no' > > Unless there are other ways to find these functions: > > >>> __builtins__.__dict__["open"]( '/etc/passwd') > > > or even: > > >>> open=lambda *x: "no" > >>> open('/etc/passwd') > 'no' > >>> del open > >>> open('/etc/passwd') > > > Python is fun, there are so many ways to have it do what you want ;) > > It might be possible to remove these functions like this: > > >>> del __builtins__.__dict__["open"] > >>> open('/etc/passwd') > Traceback (most recent call last): > File "", line 1, in > NameError: name 'open' is not defined > [...] > > But i don't know whether that'd get rid of all problems. > > Best regards, > > Lutz > Hi, The quick answer is no, it wouldn't be enough. For example, try type(sys.stdin)('/etc/passwd') or the equivalent sys.stdin.__class__('/etc/passwd'). Also, as http://mail.python.org/pipermail/python-dev/2006-July/067291.html points out, file can be obtained from object.__subclasses__(). (object itself can be found by working up the inheritance tree from any new-style class - say, a string - using __bases__) Python's powerful introspection support and lack of data hiding make doing any sort of meaningful sandboxing within the language itself very difficult. There used to be a bundled module called rexec to do this (via a combination of hooks into the interpreter and built-in support), but it was depreciated due to security issues. They might be doing something similar - it seems to strip what functions from native-code modules can be imported to some safe whitelist (and load all modules written in Python within the sandbox). Aidan From tqbf at matasano.com Sat Apr 12 14:22:15 2008 From: tqbf at matasano.com (Thomas Ptacek) Date: Sat, 12 Apr 2008 13:22:15 -0500 Subject: [Dailydave] Google Apps Engine In-Reply-To: References: <47FB7EA9.2000503@immunityinc.com> <20080408152649.GA797@ark.ibm.com> <20080411143314.GA25341@localhost> Message-ID: <1df0a410804121122q69c53428h9f8b0466df6a6479@mail.gmail.com> If you own the interpreter codebase, shouldn't it be possible just to hook libc's open(2) stub, and give a unique signature to calls that originated on a trusted code path? This doesn't seem at all hard to me. On 4/12/08, Aidan Thornton wrote: > > On 4/11/08, Lutz B?hne wrote: > > > Even those could easily be sanitized by just some fun with function > > > pointers. > > > > > > >>> open=lambda *x: "no" > > > >>> open('/etc/passwd') > > > 'no' > > > > Unless there are other ways to find these functions: > > > > >>> __builtins__.__dict__["open"]( '/etc/passwd') > > > > > > or even: > > > > >>> open=lambda *x: "no" > > >>> open('/etc/passwd') > > 'no' > > >>> del open > > >>> open('/etc/passwd') > > > > > > Python is fun, there are so many ways to have it do what you want ;) > > > > It might be possible to remove these functions like this: > > > > >>> del __builtins__.__dict__["open"] > > >>> open('/etc/passwd') > > Traceback (most recent call last): > > File "", line 1, in > > NameError: name 'open' is not defined > > [...] > > > > But i don't know whether that'd get rid of all problems. > > > > Best regards, > > > > Lutz > > > > > Hi, > > The quick answer is no, it wouldn't be enough. For example, try > type(sys.stdin)('/etc/passwd') or the equivalent > sys.stdin.__class__('/etc/passwd'). Also, as > http://mail.python.org/pipermail/python-dev/2006-July/067291.html > points out, file can be obtained from object.__subclasses__(). (object itself can be found by working up the inheritance tree from any new-style class - say, a string - using __bases__) > > Python's powerful introspection support and lack of data hiding make > doing any sort of meaningful sandboxing within the language itself very difficult. There used to be a bundled module called rexec to do this (via a combination of hooks into the interpreter and built-in support), but it was depreciated due to security issues. They might be doing something similar - it seems to strip what functions from native-code modules can be imported to some safe whitelist (and load all modules written in Python within the sandbox). > > > Aidan > > _______________________________________________ > 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 Brian at cms.ca Tue Apr 15 16:04:26 2008 From: Brian at cms.ca (Brian Bourne) Date: Tue, 15 Apr 2008 16:04:26 -0400 Subject: [Dailydave] SecTor 2008 Call for Speakers - First Round Submissions April 30 Deadline Message-ID: <0880489754536A46AB2BC2EDA311969EBE9957B1A7@mail2k7.corp.cms.ca> SecTor 2008 is currently open to speaking proposals. Visit http://www.sector.ca/ to learn more about the event. SecTor is all about the meat -- The content that matters to Canadian IT Security Professionals today. Of course we'll have fun and celebrate having the world's best in Toronto, but the key to SecTor's success, and thus the primary objective of the Management Committee and Advisory Committee, is quality content and presentation for attendees. This is a call for speakers/papers. If we haven't approached you, but you believe you have a significant discovery or new research that the security community would value, or enjoy hearing about, we invite you to submit your presentation topic for serious consideration. Selected speakers will have travel costs covered. To be included in first round speaker selection, please make your proposal submissions before April 30th, 2008. The first round of speakers will be announced in the middle of May. You will not be contacted until that time. To allow for late breaking research to be presented, additional submissions will be accepted until August 31, 2008. This second round of speakers will be announced in early September. SecTor attendees are a mix of security professionals and vendors, programmers, students, network administrators and IT executives. Preference will be given to speakers who can present new and innovative technical content to a broad audience. Of course, all presentations are expected to challenge the brightest and quickest of attendees - we wouldn't have it any other way. SecTor is not a vendor fair. Consequently, there will be very little tolerance for commercial content within presentations. Attendees will be encouraged to quell any shameless marketing that is not immediately backed up with rationale for its inclusion. Proposals should consist of the following information: 1. Presenter and contact info (country of origin and residence-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. Optionally, any samples of prepared material or outlines ready. 8. Will you have full text available or only slides? 9. Please list any other publications or conferences where this material has been or will be published/submitted. Please include the plain text version of this information in your email as well as any file, pdf, sxw, ppt, or html attachments. Please forward the above information to management at sector.ca. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20080415/4cf66659/attachment.htm From cmiller at securityevaluators.com Wed Apr 16 19:52:46 2008 From: cmiller at securityevaluators.com (Charles Miller) Date: Wed, 16 Apr 2008 18:52:46 -0500 Subject: [Dailydave] Cats out of the bag Message-ID: <9962FCF4-5289-4150-B242-A9865514129C@securityevaluators.com> Well, Apple patched the CanSecWest bug today. Now I guess I can say you sneaky people with your "svn" hacker tool were right! I can't believe I kept my mouth shut this long, but then again, I'd do a lot for 10k. Charlie From erey at ernw.de Thu Apr 17 17:21:07 2008 From: erey at ernw.de (Enno Rey) Date: Thu, 17 Apr 2008 23:21:07 +0200 Subject: [Dailydave] [dave@immunityinc.com: I love the smell of Cisco remotes in the morning] Message-ID: <20080417212107.GC85795@ws25.ernw.de> List, in the meantime we've expanded the stuff a bit. The code for SPIKE and Sulley (+ the Shmoo08 presentation) can be found here: http://www.ernw.de/download/l2spike_04-15-08.tar.bz2 http://www.ernw.de/download/l2sulley_04-15-08.tar.bz2 http://www.ernw.de/download/l2_fuzzing_shmoo08.pdf Most of the work has been done on Sulley scripts. Now there are some (not tested too extensively so far) on: arp, dtp, lldp (bit fields still missing), lwapp, pvstp, udld, vtp, cdp, edp, mpls, stp, vrrp, wlccp ============ Dave, in particular for SPIKE some words below. thanks, Enno -- Enno Rey Check out www.troopers08.org! ========================================================================= New Spike L2 Version released We are happy to announce the relase of a new Version of SPIKE_L2 Fuzzing-Framework. It mainly consists of the original SPIKE 2.9 and a few new functions with the focus on layer 2 fuzzing. This "add-on" for SPIKE is the output of one of our research projects. The goal of this project was to evaluate the security of network devices and to get a better understanding of some protocols and the fuzzing process in protocol space. The layer 2 stuff is based on libnet and like the original SPIKE 2.9 runs only on linux. To compile just: ./configure make =======New Functions=============== - l2_write_data() - s_binary_type_and_block_size_lldp() - s_random_fuzz() and s_random_fuzz_repeat() - s_binary_selection() - s_string_variable_sized() For more details take a look at the changelog =======Layer2 Protocol-Scripts===== - ARP - DTP - VTP - LLDP - MPLS Now layer 2 fuzzing is as easy as fuzzing on tcp or udp! ======================================================================== ----- Forwarded message from Dave Aitel ----- -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 So there was a talk at Shmoocon about modifying SPIKE 2.9 to be a decent fuzzer for Layer 2. During the talk they demonstrated a remote stack overflow in some Cisco box via some random L2 protocol I'd never heard of before. That was very cool. :> This has an earlier version of their talk. At some point they're going to put their modified SPIKE online, so everyone can find cool L2 bugs, although for their newer work I believe they've switch to Sulley. http://www.day-con.org/2007/l2_fuzzing_v099r_ger.pdf - -dave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHuGE7tehAhL0gheoRArKqAJ9MzilSKaJI9mfZMcwHe65WEiaw1gCfQi61 LDtWk6eKuBHX5KCdmLOgzKk= =S1Mj -----END PGP SIGNATURE----- _______________________________________________ Dailydave mailing list Dailydave at lists.immunitysec.com http://lists.immunitysec.com/mailman/listinfo/dailydave ----- End forwarded message ----- -- Enno Rey Check out www.troopers08.org! ERNW GmbH - Breslauer Str. 28 - 69124 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 PGP FP 055F B3F3 FE9D 71DD C0D5 444E C611 033E 3296 1CC1 Handelsregister Heidelberg: HRB 7135 Geschaeftsfuehrer: Roland Fiege, Enno Rey From sqlsec at yahoo.com Sat Apr 19 12:21:36 2008 From: sqlsec at yahoo.com (Cesar) Date: Sat, 19 Apr 2008 09:21:36 -0700 (PDT) Subject: [Dailydave] Token Kidnapping (Microsoft Security Advisory 951306) presentation available Message-ID: <87320.41767.qm@web33001.mail.mud.yahoo.com> Presentation is available at: http://www.argeniss.com/research/TokenKidnapping.pdf Exploit code won't be released for a while due to Microsoft request. Enjoy. Cesar. ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ From James.R.Lindley at irs.gov Mon Apr 21 09:19:04 2008 From: James.R.Lindley at irs.gov (Lindley James R) Date: Mon, 21 Apr 2008 09:19:04 -0400 Subject: [Dailydave] Employment Opportunities for Java/.NET Programmers and pen-testers Message-ID: <64CB1CAFF7F54943AC711BFA52C54B770329F2D0@NCT0010CP3MB01.ds.irsnet.gov> Employment Opportunities for Java/.NET Programmers and pen-testers The Internal Revenue Service IT Security Architecture and Engineering's Advanced Technical Analysis Team (ITSAE@@) has "Immediate Hire" authority to hire programmers who have very competent to outstanding skills in Java or .NET environments and equally qualified penetration testers. Programmers would be trained in application security using the a combination of their skills and the latest static source code analysis tools (Fortify, Ounce Labs, Klocwork, Code Sonar). Pen-testers would focus on dynamic application-focused testing using a combination of their skills and the latest application-focused penetration tools (Hailstorm, Metasploit, etc.). ITSAE provides security architectural and engineering support to the project teams working on hundreds of annual IT project at the IRS. We focus on creating the security that the FISMA certification and accreditation process documents. We are NOT a documentation team, but work directly with IT project teams to provide knowledge, recommendations, and risk assessments. If you've ever wanted to do security engineering that actually results in improved security, this is it! ITSAE is in the process of standing up an Advanced Technical Analysis Team, whose purpose will be to provide "in-development" and "pre-implementation" security artifact assessment, analyzing software architectures and implementations from requirements through design, tool and product specification, coding, installation, and user configuration. This Team will perform static source code security assessments, application focused penetration testing, recommend architectural and implementation mitigations, and assess residual risk in finished products. This is a very collegial organization of highly skilled individuals where knowledge is the "coin of the realm." We may be the highest ranking collection of non-manager wire heads and bit-twiddlers in the IRS and maybe the whole federal government. The truth of the above statement is reflected in the hiring levels for the positions mentioned above. We are looking for two GS-14s and two GS-15s with hiring level determined by applicant skill levels. The normal federal employment background check is required. Work location would be at the New Carrollton Federal Building (NCFB) in Lanham, Maryland. The complex is directly adjacent to the Washington New Carrollton Metro Station. The job includes a Public Transportation Subsidy Program. Resumes should be submitted ASAP to James.R.Lindley at irs.gov. Thanx for your time. JimL James R Lindley Senior Computer Engineer CISSP-ISSAP/ISSEP/ISSMP, CISA, PMP, CHS-III, CNE, SSE-CMM Appraiser, MCSE, MCT, CNSS 4013, A+ IT Security Architecture and Engineering MITS System Integration An unquenchable thirst for Pierian waters. James R Lindley Senior Computer Engineer CISSP-ISSAP/ISSEP/ISSMP, CISA, PMP, CHS-III, CNE, SSE-CMM Appraiser, MCSE, MCT, CNSS 4013, A+ IT Security Architecture and Engineering MITS System Integration OS:CIO:ES:SI:SE:SA Cube: NCFB C6-462 Cube: 202-283-1590 Cell: 410-703-4127 An unquenchable thirst for Pierian waters. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20080421/f02b1d81/attachment.htm From talg at stanford.edu Wed Apr 23 13:26:03 2008 From: talg at stanford.edu (Tal Garfinkel) Date: Wed, 23 Apr 2008 10:26:03 -0700 Subject: [Dailydave] Denial of Service via Algorithmic Complexity Message-ID: There has been some work done on the issue that dave mentioned about exploiting the complexity of certain program operations for efficient denial of service by Scott Crosby and Dan Wallach from Rice. They looked at how this type of attack could be used against the Bro IDS, among other things... you can check out their Usenix Security paper, example code, and pointers to related work here. http://www.cs.rice.edu/~scrosby/hash/ Cheers, Tal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20080423/83034ef5/attachment.htm From dave.aitel at gmail.com Thu Apr 24 07:27:18 2008 From: dave.aitel at gmail.com (Dave Aitel) Date: Thu, 24 Apr 2008 07:27:18 -0400 Subject: [Dailydave] Vista SP1 Message-ID: Vista SP1 was released to Automatic Update. One thing about SP1 is that it breaks the Flash exploit Mark Dowd describes in his paper by making certain memory NX. There's lots of other interesting ways to exploit it, which should result in lots of other cool papers. :> -dave -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20080424/6cadd926/attachment.htm From dave at immunityinc.com Thu Apr 24 16:51:04 2008 From: dave at immunityinc.com (Dave Aitel) Date: Thu, 24 Apr 2008 16:51:04 -0400 Subject: [Dailydave] Two thoughts for the day: Message-ID: <4810F2B8.8080507@immunityinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 1. The sky is not falling and Microsoft does not have to rewrite their entire patch system to solve any pressing problems. (http://www.securityfocus.com/news/11514). 2. Penetration testing frameworks need to have a whole trojan framework as well. Our Kernel Rootkit needs to be able to install, uninstall, upgrade, trigger, and otherwise manipulate PINK or the MOSDEFService.exe. PINK 1.0 just got released and I find it quite interesting to see people's reactions to it. - -dave One last seat available in CANVAS training class next week in Miami Beach. May 1 & 2. $2000. Details here: http://www.immunityinc.com/education-canvas.shtml -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIEPK3tehAhL0gheoRAobNAJ98X6A0ENCi20xOCIEVdgSOMh5UJQCfdtv8 J0W8K4nMdmNVOTEFfbLUyQQ= =uKo3 -----END PGP SIGNATURE----- From alex at sotirov.net Thu Apr 24 21:57:51 2008 From: alex at sotirov.net (Alexander Sotirov) Date: Thu, 24 Apr 2008 18:57:51 -0700 Subject: [Dailydave] Vista SP1 In-Reply-To: References: Message-ID: <20080425015751.GA3248@dsl093-068-003.sfo1.dsl.speakeasy.net> On Thu, Apr 24, 2008 at 07:27:18AM -0400, Dave Aitel wrote: > Vista SP1 was released to Automatic Update. One thing about SP1 is that it > breaks the Flash exploit Mark Dowd describes in his paper by making certain > memory NX. What memory does SP1 make NX? The iexplore.exe process is not on the OptIn DEP list in Vista SP1, so everything in memory is always executable. 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/20080424/c0d3a030/attachment-0001.pgp From contest at racetozero.net Fri Apr 25 08:38:28 2008 From: contest at racetozero.net (Race to Zero Organizers) Date: Fri, 25 Apr 2008 13:38:28 +0100 Subject: [Dailydave] Race to Zero - DefCon 16 contest announcement Message-ID: <20BF60AD-7A48-4FCC-83C6-D827DC39831F@racetozero.net> ========================================= Race-to-Zero - Threat Obfuscation Contest ========================================= This is a community announcement for the first Race-to-Zero contest. Race-To-Zero will be taking place at Defcon 16 and we thought members of this list may be interested in competing. The event involves contestants being given a sample set of viruses, malcode and exploits to modify and upload through the contest portal. The portal passes the modified samples through a number of antivirus engines and determines if the sample is a known threat (ala VirusTotal). The first team (or individual) to pass their sample past all antivirus engines undetected wins that round. Each round increases in complexity as the contest progresses. In addition to the overall winner, awards will be given for other notable achievements, such as: - Most elegant obfuscation - Dirtiest hack of an obfuscation - Comedy value - Most deserving of beer - .... The judging panel is currently being finalised and will be published in short order. If this sounds like your cup of tea then drop us a line at [contest[ ]racetozero[ ]net] and sign up for the fun. Further details can be found at: Contest website: http://www.racetozero.net DefCon Official Contests Thread: https://forum.defcon.org/forumdisplay.php?f=419 DefCon Official Website: https://www.defcon.org Suggestions or questions are also very welcome, nothing is set in stone quite yet so if you have ideas be sure to let us know :) Cheers Rich & Si From dave at immunityinc.com Fri Apr 25 08:41:23 2008 From: dave at immunityinc.com (Dave Aitel) Date: Fri, 25 Apr 2008 08:41:23 -0400 Subject: [Dailydave] Vista SP1 In-Reply-To: <20080425015751.GA3248@dsl093-068-003.sfo1.dsl.speakeasy.net> References: <20080425015751.GA3248@dsl093-068-003.sfo1.dsl.speakeasy.net> Message-ID: <4811D173.8070602@immunityinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've been told (although I did not write that exploit, Kostya did) that you end up using opcodes in your bytecode stream to get execution. This would mean that the bytecode stream has to be executable, which SP1 breaks. Not that this breaks the many other ways you can write the exploit, but it would make it slightly harder. I could be wrong on this - -dave Alexander Sotirov wrote: | On Thu, Apr 24, 2008 at 07:27:18AM -0400, Dave Aitel wrote: |> Vista SP1 was released to Automatic Update. One thing about SP1 is that it |> breaks the Flash exploit Mark Dowd describes in his paper by making certain |> memory NX. | | What memory does SP1 make NX? The iexplore.exe process is not on the OptIn DEP | list in Vista SP1, so everything in memory is always executable. | | Alex -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIEdFztehAhL0gheoRAr/tAJ9MDoOPD4KLnmeaOglze/rvDCRq4QCfU+l/ R1DBA7fZM/p6bc4mXmAI77U= =C+LF -----END PGP SIGNATURE----- From dave at immunityinc.com Fri Apr 25 09:05:53 2008 From: dave at immunityinc.com (Dave Aitel) Date: Fri, 25 Apr 2008 09:05:53 -0400 Subject: [Dailydave] APEG Message-ID: <4811D731.20905@immunityinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm reading that APEG paper again. This statement is not true, obviously. :> """ Determining the specific address for a successful control hijack requires predicting the processes memory layout, which changes each time the process is invoked. Attackers currently do this by essen- tially repeatedly launching an attack until the memory layout matches what the exploit expects. We similarly repeatedly launch the attack until we achieve a success- ful control hijack. """ I'm a little confused as to what extent they generated real input. It's one thing to send input directly to IGMPrcvPacket via the debugger and another thing to do it from the network. Hmm. So it seems maybe it looks more like this: First you send some IGMP data to the server and look at the path of instructions it executes (to get a call tree as close as possible to the patch). Then you do static analysis to see if you can get from the closest point you got to, to the patched instructions. Then you try to change the input from there to reach the check while at the same time solving to make sure it doesn't cause the input to fail the earlier checks and not reach your vulnerable function. Does that sound right? Maybe someone can clue me in on how far off I am. - -dave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIEdcwtehAhL0gheoRAqL9AJ40rU8NxWk4Bmh25bw0OsQoe8o90ACcD3X8 /JAOuBEIQBot/pfgasxvJcA= =ijzm -----END PGP SIGNATURE----- From joanna at invisiblethings.org Fri Apr 25 09:19:10 2008 From: joanna at invisiblethings.org (Joanna Rutkowska) Date: Fri, 25 Apr 2008 15:19:10 +0200 Subject: [Dailydave] Two thoughts for the day: In-Reply-To: <4810F2B8.8080507@immunityinc.com> References: <4810F2B8.8080507@immunityinc.com> Message-ID: <4811DA4E.2030801@invisiblethings.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dave Aitel wrote: | 2. Penetration testing frameworks need to have a whole trojan | framework as well. Our Kernel Rootkit needs to be able to install, | uninstall, upgrade, trigger, and otherwise manipulate PINK or the | MOSDEFService.exe. PINK 1.0 just got released and I find it quite | interesting to see people's reactions to it. | | Is there a technical paper about your Kernel Rootkit available somewhere? joanna. -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJIEdpMAAoJEMwG7MOLAMOlSfQH/jDnEpYdTjs8LABeEKz2XR3B 9UMgZk7Ol/wKSRKRFly3MqyPtvBl+bOarK/BxgvmKrLbv9DgFkIZ+9KYxr6pE98v R7zGobJM6DUydyCo18j0xdFgRKunjPsj/NJdcPYSzLLDw/Zovlsf7Jun+u/HmKV2 e0D6mlW/MEOaPsruWBa73OwSYqDvw/Lo87Cq2rDEpDvdJlogoOXASjT+zPm5MCVH IIQzz26dLr1KNQbVg4etA2bKlp5khG+H1px0FYccZS66GspJHFTK2naEDyh3pFkx ebk4iB+qYsbeSPssE9ohYUSw74DVKWM0HEzWhu0zY/BmBKP9NEco2ZaKY4eAgiQ= =JzzF -----END PGP SIGNATURE----- From pusscat at metasploit.com Fri Apr 25 09:10:36 2008 From: pusscat at metasploit.com (Pusscat) Date: Fri, 25 Apr 2008 09:10:36 -0400 Subject: [Dailydave] Two thoughts for the day: In-Reply-To: <4810F2B8.8080507@immunityinc.com> References: <4810F2B8.8080507@immunityinc.com> Message-ID: <8e00af420804250610x15809cccgbb54f5e49472660a@mail.gmail.com> I've got to really agree strongly concerning point #1, for two main reasons: 1. We've been turning around the patch->exploit process before full deployment for years now, sometimes before autoupdate even sees the patches in the US. 2. The work presented ignores the most time consuming portion of the exercise, being the attack vector discovery. It only automates the portion which takes a negligable amount of time when compared to the rest of the work needed to produce a viable exploit. On Thu, Apr 24, 2008 at 4:51 PM, Dave Aitel wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > 1. The sky is not falling and Microsoft does not have to rewrite their > entire patch system to solve any pressing problems. > (http://www.securityfocus.com/news/11514). > > 2. Penetration testing frameworks need to have a whole trojan framework > as well. Our Kernel Rootkit needs to be able to install, uninstall, > upgrade, trigger, and otherwise manipulate PINK or the > MOSDEFService.exe. PINK 1.0 just got released and I find it quite > interesting to see people's reactions to it. > > > - -dave > > One last seat available in CANVAS training class next week in Miami > Beach. May 1 & 2. $2000. Details here: > http://www.immunityinc.com/education-canvas.shtml > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFIEPK3tehAhL0gheoRAobNAJ98X6A0ENCi20xOCIEVdgSOMh5UJQCfdtv8 > J0W8K4nMdmNVOTEFfbLUyQQ= > =uKo3 > -----END PGP SIGNATURE----- > > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave > From halvar at gmx.de Fri Apr 25 10:53:35 2008 From: halvar at gmx.de (Halvar Flake) Date: Fri, 25 Apr 2008 16:53:35 +0200 Subject: [Dailydave] Two thoughts for the day: In-Reply-To: <4810F2B8.8080507@immunityinc.com> References: <4810F2B8.8080507@immunityinc.com> Message-ID: <4811F06F.6010806@gmx.de> Hey all, regarding #1: I have written a rather lengthy post about this topic on my blog (addxorrol.blogspot.com) if anyone cares :) Cheers, Halvar From dave at immunityinc.com Fri Apr 25 10:54:22 2008 From: dave at immunityinc.com (Dave Aitel) Date: Fri, 25 Apr 2008 10:54:22 -0400 Subject: [Dailydave] Vista SP1 In-Reply-To: <4811D173.8070602@immunityinc.com> References: <20080425015751.GA3248@dsl093-068-003.sfo1.dsl.speakeasy.net> <4811D173.8070602@immunityinc.com> Message-ID: <4811F09E.3090605@immunityinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dave Aitel wrote: | I've been told (although I did not write that exploit, Kostya did) that | you end up using opcodes in your bytecode stream to get execution. This | would mean that the bytecode stream has to be executable, which SP1 | breaks. Not that this breaks the many other ways you can write the | exploit, but it would make it slightly harder. | | I could be wrong on this | -dave Kostya tells me I'm misunderstood him and that you're only protected from that technique if you've done "OptOut" which is not the default. Still, it would be cool to defeat DEP with this exploit. Perhaps without any x86 at all! - -dave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIEfCdtehAhL0gheoRAi0vAJ4srUznlAC+1seavIsrXPMJ59NHLwCeNKVI Y86cPFqo31TsLTGgyultPR8= =dLSe -----END PGP SIGNATURE----- From rhensing at microsoft.com Fri Apr 25 10:56:10 2008 From: rhensing at microsoft.com (Robert Hensing (EL CONQUISTADOR)) Date: Fri, 25 Apr 2008 07:56:10 -0700 Subject: [Dailydave] Vista SP1 In-Reply-To: <4811D173.8070602@immunityinc.com> References: <20080425015751.GA3248@dsl093-068-003.sfo1.dsl.speakeasy.net> <4811D173.8070602@immunityinc.com> Message-ID: <402367841A0C2A4881B1952EEC3178C320990D39C7@NA-EXMSG-C113.redmond.corp.microsoft.com> I think you are wrong. :) As Alexander mentioned - IE on Vista SP1 does not opt-in to DEP by default still and I have verified that the Jscript heaps are still executable until you DO opt IE into DEP (and after doing so I have verified that standard heap spray techniques would fail). Incidentally I've emailed Mark Dowd to see if he could test his exploit with IE opted-in to DEP for me and he hasn't gotten back with me yet so it's not clear if DEP will prevent the bytecode from executing or not. I do know that Flash seems to work fine with DEP enabled in IE - so I'm assuming that Adobe is using VirtualProtect() to properly mark the pages that they need to be executable, as executable which would lead me to believe that Dowd's exploit would still work - even with DEP enabled (well - I'm assuming the AS bytecode would run - not sure about the x86 shellcode stage or where that could would be executing from - but if the x86 shellcode is also in pages marked executable by Adobe - then it's unlikely DEP would be effective here). Incidentally - ASLR *would* have been effective in stopping his exploit - but Adobe doesn't opt-in to that with Flash yet . . . but that doesn't mean YOU can't. You can use link.exe to edit the flash9f.ocx and make it use ASLR. :) -----Original Message----- From: dailydave-bounces at lists.immunitysec.com [mailto:dailydave-bounces at lists.immunitysec.com] On Behalf Of Dave Aitel Sent: Friday, April 25, 2008 8:41 AM To: Alexander Sotirov; dailydave Subject: Re: [Dailydave] Vista SP1 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've been told (although I did not write that exploit, Kostya did) that you end up using opcodes in your bytecode stream to get execution. This would mean that the bytecode stream has to be executable, which SP1 breaks. Not that this breaks the many other ways you can write the exploit, but it would make it slightly harder. I could be wrong on this - -dave Alexander Sotirov wrote: | On Thu, Apr 24, 2008 at 07:27:18AM -0400, Dave Aitel wrote: |> Vista SP1 was released to Automatic Update. One thing about SP1 is that it |> breaks the Flash exploit Mark Dowd describes in his paper by making certain |> memory NX. | | What memory does SP1 make NX? The iexplore.exe process is not on the OptIn DEP | list in Vista SP1, so everything in memory is always executable. | | Alex -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIEdFztehAhL0gheoRAr/tAJ9MDoOPD4KLnmeaOglze/rvDCRq4QCfU+l/ R1DBA7fZM/p6bc4mXmAI77U= =C+LF -----END PGP SIGNATURE----- _______________________________________________ Dailydave mailing list Dailydave at lists.immunitysec.com http://lists.immunitysec.com/mailman/listinfo/dailydave From jf at danglingpointers.net Fri Apr 25 19:15:02 2008 From: jf at danglingpointers.net (jf) Date: Fri, 25 Apr 2008 23:15:02 +0000 (UTC) Subject: [Dailydave] Two thoughts for the day: In-Reply-To: <8e00af420804250610x15809cccgbb54f5e49472660a@mail.gmail.com> References: <4810F2B8.8080507@immunityinc.com> <8e00af420804250610x15809cccgbb54f5e49472660a@mail.gmail.com> Message-ID: > 2. The work presented ignores the most time consuming portion of the > exercise, being the attack vector discovery. It only automates the > portion which takes a negligable amount of time when compared to the > rest of the work needed to produce a viable exploit. indeed, they keep saying 'exploit' when they mean 'dos poc', which is indeed impressive in itself, but only mildly useful. From valsmith at offensivecomputing.net Fri Apr 25 13:09:39 2008 From: valsmith at offensivecomputing.net (val smith) Date: Fri, 25 Apr 2008 11:09:39 -0600 Subject: [Dailydave] Two thoughts for the day: In-Reply-To: <4811F06F.6010806@gmx.de> References: <4810F2B8.8080507@immunityinc.com> <4811F06F.6010806@gmx.de> Message-ID: I'll have to be honest, I don't really WANT Microsoft to change their patch methodology, even if the dramatic (probably incorrect) conclusions people seem to be drawing from this paper are true. Bear with me for a moment and Ill explain why. Lets be honest here, there are researchers (many on this list) who can rapidly find and exploit vulnerabilities. Patches help speed things up but BinDiff (and similar) things have been available for many years and the people who can write exploits understand this process and those with a financial stake in it have automated much of the process by now. If patches were to be obfuscated, or the process changed how long would it really take for someone to circumvent it? A binary has to exist somewhere at some point right? Someone smart enough will eventually send input to it, or reverse it or accidentally crash it eventually. Many of us make use of exploits and vulnerabilities in some way for a living whether we are pen testers, IDS sig developers, vuln researchers, framework builders or whatever. At this point security is such a tangled, many layered labyrinth that I no longer possess the self righteous fury required to shout from the pulpit: "Patch your systems! Configure security! Use an IDS! Educate your users!" I'm in it for the fun. There I said it. If everyone did everything securely, I wouldn't have much to do and I'd have to pour coffees or flip burgers for a living. I like showing up for a pen test and finding unpatched boxes, or users sharing admin passwords. I love finding web apps with null byte file inclusion bugs, or passwordless ssh keys with sudo permissions on every server. Its FUN. I suspect other security researchers have reached this conclusion (even if they haven't admitted it to themselves yet) that security is probably too hard a problem to "solve" and all our ranting really doesn't make anyone more secure in the long run. At this point, broken things are fun and we just want to play and thankfully people are willing to pay for it. I don't mind if you continuously make it just a little bit harder, just to keep it interesting, but don't take away my exploits please! ;) V. On Fri, Apr 25, 2008 at 8:53 AM, Halvar Flake wrote: > Hey all, > > regarding #1: I have written a rather lengthy post about this topic on > my blog (addxorrol.blogspot.com) if anyone cares :) > > Cheers, > Halvar > > > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave > From tqbf at matasano.com Fri Apr 25 15:05:38 2008 From: tqbf at matasano.com (Thomas Ptacek) Date: Fri, 25 Apr 2008 14:05:38 -0500 Subject: [Dailydave] Two thoughts for the day: In-Reply-To: References: <4810F2B8.8080507@immunityinc.com> <8e00af420804250610x15809cccgbb54f5e49472660a@mail.gmail.com> Message-ID: <1df0a410804251205u65aa8627o5c6995260f3364f2@mail.gmail.com> It's also backtested, so who knows how realistic the data set they're working with is? It's "automated", and large data sets (all MSFT security patches) are available. Presumably, if this system worked as well as the press says it works, they could have run it against many more patches and had a more compelling paper. That they didn't tells you something. Smarter people than me disagree with this point, but I'll make it anyways: there isn't necessarily a 1:1 mapping between patches and exploitable code paths. So I kind of disagree with the premise, too. On 4/25/08, jf wrote: > > 2. The work presented ignores the most time consuming portion of the > > exercise, being the attack vector discovery. It only automates the > > portion which takes a negligable amount of time when compared to the > > rest of the work needed to produce a viable exploit. > > > > indeed, they keep saying 'exploit' when they mean 'dos poc', which is > indeed impressive in itself, but only mildly useful. > > > _______________________________________________ > 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 kostya.kortchinsky at gmail.com Fri Apr 25 15:26:50 2008 From: kostya.kortchinsky at gmail.com (Kostya Kortchinsky) Date: Fri, 25 Apr 2008 15:26:50 -0400 Subject: [Dailydave] Vista SP1 In-Reply-To: <402367841A0C2A4881B1952EEC3178C320990D39C7@NA-EXMSG-C113.redmond.corp.microsoft.com> References: <20080425015751.GA3248@dsl093-068-003.sfo1.dsl.speakeasy.net> <4811D173.8070602@immunityinc.com> <402367841A0C2A4881B1952EEC3178C320990D39C7@NA-EXMSG-C113.redmond.corp.microsoft.com> Message-ID: <2f54ad410804251226l41879796r19759e897d61c02a@mail.gmail.com> Switching to DEP OptOut prevented the exploitation. By carefully following Mark's steps, when restoring EIP from the saved pointer to your bytecode, you end up with an access violation on executing your marker byte (which at this point is followed by the call backwards) since it's not in an executable page. And bytecode is data, not actual x86 instructions to be executed. Kostya 2008/4/25, Robert Hensing (EL CONQUISTADOR) : > > I think you are wrong. :) > > As Alexander mentioned - IE on Vista SP1 does not opt-in to DEP by default > still and I have verified that the Jscript heaps are still executable until > you DO opt IE into DEP (and after doing so I have verified that standard > heap spray techniques would fail). Incidentally I've emailed Mark Dowd to > see if he could test his exploit with IE opted-in to DEP for me and he > hasn't gotten back with me yet so it's not clear if DEP will prevent the > bytecode from executing or not. I do know that Flash seems to work fine > with DEP enabled in IE - so I'm assuming that Adobe is using > VirtualProtect() to properly mark the pages that they need to be executable, > as executable which would lead me to believe that Dowd's exploit would still > work - even with DEP enabled (well - I'm assuming the AS bytecode would run > - not sure about the x86 shellcode stage or where that could would be > executing from - but if the x86 shellcode is also in pages marked executable > by Adobe - then it's unlikely DEP wo > uld be effective here). Incidentally - ASLR *would* have been effective > in stopping his exploit - but Adobe doesn't opt-in to that with Flash yet . > . . but that doesn't mean YOU can't. You can use link.exe to edit the > flash9f.ocx and make it use ASLR. :) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20080425/df617604/attachment.htm From alex at sotirov.net Sat Apr 26 15:18:25 2008 From: alex at sotirov.net (Alexander Sotirov) Date: Sat, 26 Apr 2008 12:18:25 -0700 Subject: [Dailydave] Vista SP1 In-Reply-To: <2f54ad410804251226l41879796r19759e897d61c02a@mail.gmail.com> References: <20080425015751.GA3248@dsl093-068-003.sfo1.dsl.speakeasy.net> <4811D173.8070602@immunityinc.com> <402367841A0C2A4881B1952EEC3178C320990D39C7@NA-EXMSG-C113.redmond.corp.microsoft.com> <2f54ad410804251226l41879796r19759e897d61c02a@mail.gmail.com> Message-ID: <20080426191825.GA3835@dsl093-068-003.sfo1.dsl.speakeasy.net> On Fri, Apr 25, 2008 at 03:26:50PM -0400, Kostya Kortchinsky wrote: > Switching to DEP OptOut prevented the exploitation. > > By carefully following Mark's steps, when restoring EIP from the saved > pointer to your bytecode, you end up with an access violation on executing > your marker byte (which at this point is followed by the call backwards) > since it's not in an executable page. > > And bytecode is data, not actual x86 instructions to be executed. I was confused because Dave was talking about something that changed in SP1, but it looks like there's no difference in the exploitation on SP0 and SP1. In in default configuration on both systems IE does not have DEP. If you switch to OptOut DEP on both SP0 and SP1, the exploit won't work because it tries to execute data. 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/20080426/4b03c759/attachment.pgp From rhyskidd at gmail.com Sun Apr 27 13:00:34 2008 From: rhyskidd at gmail.com (Rhys Kidd) Date: Mon, 28 Apr 2008 01:00:34 +0800 Subject: [Dailydave] Information leak over RPC of a heap pointer to caller controlled data Message-ID: <68dd869f0804271000h49fc6312o5d6765d4ea343942@mail.gmail.com> In late 2006 the following oddity was discovered in the Windows XP Server Service RPC interface; it has been resolved in Service Pack 3. When calling a number of functions on the srvsvc RPC interface (4B324fC8-1670-01D3-1278-5A47BF6EE188), the stub returned will contain a pointer to caller-controlled data on the heap. A classical information leak. Example functions that exhibit this behaviour include: - Opnum 0x00 - NetCharDevEnum (also detailed by Derek Soeder - http://research.eeye.com/html/Papers/download/eeyeMRV-Oct2006.pdf) - Opnum 0x01 - NetrCharDevQEnum (reported by myself to Microsoft) As was well explained in Derek's paper on uninitialised memory, these are of a class of memory retrieval issues, which allow some unique fingerprinting of remote memory structures and their locations. Demonstrations of this were built on top of Metasploit's RPC stack, and have been withheld from public disclosure until this point in time. For the curious, the patch causes the functions to mimic their Windows Server and Vista counterparts - which always returned 0x00200000 as the pointer value. I didn't place much further thought into this until Druid's paper on *Context-keyed Payload Encoding. *This method would allow a payload decoding key to be inserted ahead of time into the target's services.exe process, with a custom value and at a known offset. http://www.uninformed.org/?v=9&a=3 Now that XP SP3 has been widely released, and this information leak resolved, the two Metasploit modules are being released in the interests of further research. Rhys msf auxiliary(srvsvc_NetrCharDevQEnum_heap) > run [*] Binding to 4b324fc8-1670-01d3-1278-5a47bf6ee188:3.0 at ncacn_np:192.168.58.128[\srvsvc] ... [*] Bound to 4b324fc8-1670-01d3-1278-5a47bf6ee188:3.0 at ncacn_np :192.168.58.128[\srvsvc] [*] Calling the vulnerable function NetrCharDevQEnum(), value=174 ... [*] Response received from remote target: [*] 01000000 01000000 00000000 00000000 fc765003 ae000000 32000000 <- 0x035076fc pointer to 0xae (174) data in memory [*] Auxiliary module execution completed -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20080428/1ab7f20b/attachment.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: srvsvc_NetrCharDevEnum_heap.rb Type: application/octet-stream Size: 3157 bytes Desc: not available Url : http://lists.immunitysec.com/pipermail/dailydave/attachments/20080428/1ab7f20b/attachment.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: srvsvc_NetrCharDevQEnum_heap.rb Type: application/octet-stream Size: 3114 bytes Desc: not available Url : http://lists.immunitysec.com/pipermail/dailydave/attachments/20080428/1ab7f20b/attachment-0001.obj From stricaud at inl.fr Mon Apr 28 10:07:45 2008 From: stricaud at inl.fr (Sebastien Tricaud) Date: Mon, 28 Apr 2008 16:07:45 +0200 (CEST) Subject: [Dailydave] [ANNOUNCE] Wolfotrack 1.0 released Message-ID: <58504.192.168.33.142.1209391665.squirrel@mail.inl.fr> Tears were flowing from our bellowed Administrators out there. Connection tracking is not always easy, hence Wolfotrack, the conntrack killer that aims to reduce the firewall use difficulty that many people complained about for years. This software makes this time gone! We are now enhancing netfilter at the user level. \o\ \o| |o| \o/ /o/ \o\ THERE IT IS /o/ \o\ |o| |o/ /o/ /o/ The long... and awaited... Netfilter connection tracking killer! The great Wolfotrack, based on our favorite game Wolfenstein 3d! You simply kill people that are tight to a state updated by the connection tracking. Everytime a door is opened, this table is refreshed. And when the actor is killed, the connection tracking associated is killed as well! Wall of Quotes ============== "With wolfotrack, I look forward new connections. Banning p2p has never been so fun !" -- Pascal Terjan, Mandriva kernel team "Obviously the most significant new firewall GUI for productivity increases and stopping real time attacks, since X-Window came out... the best way for firewall admins to understand what's going on, track it down, and kill it." -- Dragos Ruiu, (Can|Eu|Pac)Sec(West|) organizer "Wolfotrack is the synthesis of the tremendous INL's experience on firewall GUI. It overruns all existing interfaces by providing amazing productivity increase for firewall administrator" -- Eric Leblond, NuFW author and INL co-founder "Wolfotrack is the most comprehensive, cutting edge, visionary tool for slaying evil guys connections as they come through, in real time, before they can harm you for good." -- Cedric Blancher, Computer Security Researcher Wolfotrack project ================== Youtube demo video: http://www.youtube.com/watch?v=z3zRnHPFPrc Project Page: http://software.inl.fr/trac/wiki/Wolfotrack Get it! ======= Tarball: http://software.inl.fr/releases/wolfotrack/wolfotrack-1.0.tar.gz Shareware data files, with Nazi symbols replaced by 'nupiks': http://www.wallinfire.net/files/wolf3d-data_nupik-shareware.tar.gz The original shareware data files can be retrieved from: ftp://ftp.3drealms.com/share/1wolf14.zip (and rename .WL1 files into lower case) Some history ============ People know how efficient psdoom is, and we needed something similar to manipulate Netfilter connection states for customers. Unfortunately, psdoom was too 'bling-bling' and may be hard to manipulate the connection states because of weapons like BFG9000. That is why Wolfenstein 3d was a natural choice. Developers ========== Sebastien Tricaud Victor Stinner Laurent Defert Build ===== cmake . make Run === $ sudo ./sdlwolf3d x3 Yes, it has to be runned as root ;-), and x3 will make the display bigger. Known Issues ============ * Demo mode: Beware, the demo mode will actually kill your connections for real. Make sure you are awake and ready :) * x86_64: Simply does not work on this architecture. The program segfaults at startup. From dave at immunityinc.com Mon Apr 28 11:26:00 2008 From: dave at immunityinc.com (Dave Aitel) Date: Mon, 28 Apr 2008 11:26:00 -0400 Subject: [Dailydave] Django Google App Engine job Message-ID: <4815EC88.7030108@immunityinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Immunity is looking for a Google App Engine: Django contract programmer. If you know one, let me know. Description: This project allows people suffering from food allergies to enter in their daily food intake (what I ate and when) and allergic reactions (reaction intensity and symptom) and then makes an informed guess at what is causing the reactions (which may be delayed by X hours, last for X hours, have some noise in the signal, etc). Often foods packaging does not list all the ingredients (aka, "colorings and flavorings"), so this will also be useful to data-mine for brands that include allergens that are not specified. Likewise, entering food ingredients is unfun and only one user should have to ever do this per food/brand. This is where Ajax comes into play, as you want to make it as easy as possibly to type in the long chemical names of things. The goal is to start at "Simple and Useful" and scale from there. Anyone with a child with a food allergy could use this service from launch-day and get lots of value. It may turn out, in fact, that "Milk is not good food". Doctor's give you food diaries to fill out - but these don't really work as anyone who's tried to use them can point out. Processed foods defeat simplistic methods of analysis as the ingredient list is too complex for people to correlate. This project solves that problem. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIFeyItehAhL0gheoRAszXAJ9b5AlxJPJSnphOWrxxAE8rP22OlQCeMf4R 2q+/ZACUZbI/l0ybnCHh7TU= =imaQ -----END PGP SIGNATURE----- From dave at immunityinc.com Mon Apr 28 11:38:16 2008 From: dave at immunityinc.com (Dave Aitel) Date: Mon, 28 Apr 2008 11:38:16 -0400 Subject: [Dailydave] Two thoughts for the day: In-Reply-To: <4811DA4E.2030801@invisiblethings.org> References: <4810F2B8.8080507@immunityinc.com> <4811DA4E.2030801@invisiblethings.org> Message-ID: <4815EF68.1030405@immunityinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 There's no paper out right now, although I am writing a generalized overview to all the trojans in CANVAS today. Essentially the kernel rootkit is very simple - it sits underneath the network layer polling for trigger packets (UDP) which then can contain a command to tell it to send a MOSDEF connection to a listening post. Also it can hide network connections (ioctl-based command-set). There's a lot more to do, of course, but the innovation in the CANVAS trojan set is not in specialized hooking techniques or new feature sets, but more in how the whole package integrates. You'll want to be able to send messages over your internal RootkitBus via your HTTP-MOSDEF callback, etc. As we integrate Immunity Debugger into CANVAS you'll see lots of "specialized hook for X app" stuff come through. Trojans are important and I've always felt that penetration testing kits leave them a bit behind. We'll fix that. :> You can always buy CANVAS Early Updates and test it for yourself. :> Of course, it breaks the CANVAS license for AV vendors to write signatures for CANVAS, so there won't be any "CANVAS Rootkit" signatures, although we do get picked up by generic signatures for things sometimes. - -dave | | Is there a technical paper about your Kernel Rootkit available somewhere? | | joanna. _______________________________________________ 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) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIFe9otehAhL0gheoRArJqAJ0Rmpg83GFNYhxrGPGVabR3b4M8wQCfTP4q 5NfeNg69CFxJJeP0O4/NI0g= =lvSZ -----END PGP SIGNATURE----- From dave at immunityinc.com Mon Apr 28 13:58:43 2008 From: dave at immunityinc.com (Dave Aitel) Date: Mon, 28 Apr 2008 13:58:43 -0400 Subject: [Dailydave] Anonymized email re: sigs Message-ID: <48161053.6010402@immunityinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 An anonymized message follows with my comments in []'s - -dave ______________________________________________________________________ Anonymize this if you want to repost - some IPS/IDS canvas sigs: On Monday 28 April 2008, Dave Aitel wrote: | > Of course, it breaks the CANVAS license for AV vendors to write | > signatures for CANVAS, so there won't be any "CANVAS Rootkit" | > signatures, although we do get picked up by generic signatures for | > things sometimes. [editor comment (dave): hmmm] TippingPoint: 4933: Canvas: Canvas Shellcode 5171: Canvas: Canvas Shellcode 5172: Canvas: Canvas Shellcode [editor comment: Some of these don't make any sense? Should BABYBOTTLE add rand(5) spaces to the front to avoid simple gzip sigs?] Juniper: CANVAS-BABYBOTTLE CANVAS-BABYBOTTLE-GZIP CANVAS:AVGTCPSRV CANVAS:CANVAS-HELIUM CANVAS:ESERV CANVAS:FEDORA4 CANVAS:INGRESS CANVAS:LINUXSNMP CANVAS:MAILENABLE CANVAS:NETWORKER-3 CANVAS:NOVELL2 CANVAS:TIVOLI3 CANVAS:WORDMAIL3 [editor comment - these are now removed from VRT] Snort: ./sid-msg.map:10506 || SHELLCODE Canvas shellcode basic encoder ./sid-msg.map:10507 || SHELLCODE Canvas shellcode basic encoder ./sid-msg.map:10508 || SHELLCODE Canvas shellcode basic encoder ./sid-msg.map:10509 || SHELLCODE Canvas shellcode basic encoder ./sid-msg.map:10510 || SHELLCODE Canvas shellcode basic encoder ./sid-msg.map:10511 || SHELLCODE Canvas shellcode basic encoder ./sid-msg.map:10512 || SHELLCODE Canvas shellcode basic encoder ./sid-msg.map:10513 || SHELLCODE Canvas shellcode basic encoder -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIFhBTtehAhL0gheoRAkxvAJ9+plM06s5O/l4M7v1L1dhNFQDB6QCePN2n b8eyXFEF1qRYaJ1QCBGG1TE= =ivQa -----END PGP SIGNATURE----- From info at d2sec.com Mon Apr 28 14:59:19 2008 From: info at d2sec.com (DSquare Security) Date: Mon, 28 Apr 2008 13:59:19 -0500 Subject: [Dailydave] Client Side Exploitation Automation Message-ID: <20080428185919.GA18360@d2sec.com> Everyone knows that client side attack is often the more efficient way to compromise a network. D2 Client Insider was designed especially for testing security by modeling this kind of attack. D2 Client Insider provide