Send Dailydave mailing list submissions to
dailydave@lists.immunitysec.com
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.immunitysec.com/mailman/listinfo/dailydave
or, via email, send a message with subject or body 'help' to
dailydave-requ...@lists.immunitysec.com
You can reach the person managing the list at
dailydave-ow...@lists.immunitysec.com
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Dailydave digest..."
Today's Topics:
1. Re: ASLR+DEP = no problem. :> (Nate Lawson)
2. Re: ASLR+DEP = no problem. :> (Berend-Jan Wever)
3. Re: ASLR+DEP = no problem. :> (Larry Seltzer)
4. Kernel bugs! (dave)
5. Re: ASLR+DEP = no problem. :> (Michal Zalewski)
6. Directory traversal as a reconnaissance tool (Russ McRee)
(Russ McRee)
7. secure priv-dropping code in python
(travis+ml-dailyd...@subspacefield.org)
8. IE Protected Mode (dave)
9. analyzing Android (travis+ml-dailyd...@subspacefield.org)
----------------------------------------------------------------------
Message: 1
Date: Thu, 04 Feb 2010 21:51:39 -0800
From: Nate Lawson <n...@root.org>
Subject: Re: [Dailydave] ASLR+DEP = no problem. :>
To: Alexander Sotirov <a...@sotirov.net>
Cc: dailyd...@lists.immunityinc.com, Thierry Zoller
<thie...@zoller.lu>
Message-ID: <4b6bb1eb.3000...@root.org>
Content-Type: text/plain; charset=ISO-8859-1
Alexander Sotirov wrote:
> On Thu, Feb 04, 2010 at 08:06:33PM +0100, Thierry Zoller wrote:
>>> now, after reading the paper let me know if it requires a 'fix' as you
>>> said, or a re-design/engineering and re-implementation of the JIT
>>> itself. ;)
>> Does not compute either. By "fix" I abviously assumed "redesign/eginner"
>> the JIT. The point was that ASLR/DEP is not dead because of error in a
>> JIT.
>
> Are you making the claim that JIT spraying can be stopped by redesigning the
> JIT? How exactly would you redesign the JIT to avoid inserting bytes
> controlled
> by the attacker into the generated instruction stream?
This is one reason why I expect the techniques of software protection to
become more widespread in general-purpose systems. Things like
obfuscation, heap randomization, integrity self-checks, linker module
encryption, etc. were once the domain of copy protection systems or the
like.
But if your JIT compiler starts generating randomized, obfuscated native
code with embedded self-checks, now it starts getting harder to use the
output in a predictable way. I see this as a natural extension of the
process that started with ASLR.
--
Nate
------------------------------
Message: 2
Date: Fri, 5 Feb 2010 11:08:43 +0100
From: Berend-Jan Wever <berendjanwe...@gmail.com>
Subject: Re: [Dailydave] ASLR+DEP = no problem. :>
To: dailyd...@lists.immunityinc.com
Message-ID:
<3fa2f5bb1002050208x7cf5ce31se6d1b9d403538...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
The way I see it DEP+ASLR tries to take the executability of controllable
bytes (DEP) and the predictability of the locations of bytes (ASLR) away
from an attacker.
I have not seen the talk or any technical information about the attack under
discussion, but I am guessing that this JIT attack generates a large number
of functions with specific content, which cause the JIT compiler to generate
a large number of executable bytes with predictable content. That means you
break DEP by generating controllable bytes that are executable and ASLR
because you can create so many copies that you can predict a location where
one of them will be.
V8 <http://code.google.com/p/v8/> has some mitigations to prevent too much
control over the bytes it generates; 32-bit hard-coded integers are split
into two 16 bit values, to prevent an attacker from having control over too
many sequential bytes. This is an attempt to prevent an attacker from
generating a sequence of useful instructions. Though I do not doubt that it
is still possible to generate code that does arbitrary things, it becomes a
lot harder.
It is possible to take control and information away from the attacker even
further by generating code in different ways each time where possible (
http://lists.immunitysec.com/pipermail/dailydave/2007-July/004471.html),
inserting random NOPs, cutting code into chunks that are connected by JMPs
and reordering these chunks as well as inserting random (unused) chunks of
bytes in between the normal code, etc.., etc...
There is of course a trade-off with speed and code size. You want to make
your compiler random enough for an attacker to have less than a 1/256 chance
of successfully executing arbitrary code. I'm guessing that making it random
enough to not allow better chances of success than ASLR is prohibitively
expensive in speed and size, especially now that speed is becoming more and
more important for browsers. You can probably decrease the chance of success
significantly below 1 though.
Cheers,
SkyLined
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.immunitysec.com/pipermail/dailydave/attachments/20100205/18df5892/attachment-0001.htm
------------------------------
Message: 3
Date: Fri, 5 Feb 2010 09:44:25 -0500
From: "Larry Seltzer" <la...@larryseltzer.com>
Subject: Re: [Dailydave] ASLR+DEP = no problem. :>
To: <dailyd...@lists.immunityinc.com>
Message-ID:
<9b9e7ea67e1b1342b2d25f3fd1b3293003365...@be35.exg3.exghost.com>
Content-Type: text/plain; charset="us-ascii"
First, it looks like insulting others is common, if not mandatory
practice on this list. Sorry if I don't do a good enough job, I'm new
here.
My first impression on seeing this (I'm still reading Dion's paper) was
that perhaps some sort of validator or IPS-like functionality in the
JIT, analyzing the input, could be effective, looking for malformations
and suspicious behavior. It couldn't be perfect and there would be a
performance hit.
My other thought was whether Java is just as vulnerable. I assume almost
all JVMs do JITing. Of course Java byte code is understood to be code
while Flash files are treated as "content". So it wouldn't be so easy,
for example, to send malicious Java to a locked Symbian cell phone
because it would have to be signed and users are generally more cautious
about code than "content".
Larry Seltzer
Contributing Editor, PC Magazine
larry_selt...@ziffdavis.com
http://blogs.pcmag.com/securitywatch/
------------------------------
Message: 4
Date: Fri, 05 Feb 2010 13:56:14 -0500
From: dave <d...@immunityinc.com>
Subject: [Dailydave] Kernel bugs!
To: dailyd...@lists.immunityinc.com
Message-ID: <4b6c69ce.80...@immunityinc.com>
Content-Type: text/plain; charset=ISO-8859-1
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
So I remember when one of the major kernel remote in Windows came out,
and Nico was down in Argentina at Ekoparty with cards that had a praying
mantis on them and read "Our other bug is a kernel remote". MS asked him
if he'd known about it before hand, and the answer, of course, was no,
he just was lucky to have neat cards ready.
Nonetheless, Kernel exploitation is a skill that is not going to get old
any time soon. In light of that, we've developed a new Kernel overflows
class (
https://www.immunityinc.com/education-kerneloverflowsandshellcodewriting.shtml
) and it's first implementation is going to be held in Akihabara,
Tokyo. It's a 4 day class which is being held on Tuesday March 2 -
Friday March 5, 2010 and it's being taught by Kostya and Ron.
For pricing or registration information, please send an e-mail to
sa...@cyberdefense.jp. I'm headed downstairs to go see if I can solve
the exercises.
- -dave
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAktsac4ACgkQtehAhL0ghernBwCffP9YGM+zRuarWww27hi4lKOd
AbYAnjIx4n3VYnCDJkuwHxnYAoZm+d7E
=x9O4
-----END PGP SIGNATURE-----
------------------------------
Message: 5
Date: Fri, 5 Feb 2010 10:54:40 -0800
From: Michal Zalewski <lcam...@coredump.cx>
Subject: Re: [Dailydave] ASLR+DEP = no problem. :>
To: Larry Seltzer <la...@larryseltzer.com>
Cc: dailyd...@lists.immunityinc.com
Message-ID:
<448e9a321002051054n2fe2e8d9obfe253a4a00f5...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
> My first impression on seeing this (I'm still reading Dion's paper) was
> that perhaps some sort of validator or IPS-like functionality in the
> JIT, analyzing the input, could be effective, looking for malformations
> and suspicious behavior.
I propose antivirus scanning.
With this problem solved, moving on to...
/mz
------------------------------
Message: 6
Date: Mon, 8 Feb 2010 12:27:14 -0800
From: Russ McRee <holisticinfo...@gmail.com>
Subject: [Dailydave] Directory traversal as a reconnaissance tool
(Russ McRee)
To: dailydave@lists.immunitysec.com
Message-ID:
<a9f482f51002081227x2c53d6csbec4df70963dc...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Directory traversal as a reconnaissance tool
http://holisticinfosec.blogspot.com/2010/02/directory-traversal-as-reconnaisance.html
Like most of you, I find malicious or fraudulent online advertisers
annoying to say the least.
My typical response, upon receipt of rogue AV pop-ups, or redirects to
clearly fraudulent sites, is to "closely scrutinize" the perpetrating
site.
This effort often bears fruit as is evident in the following analysis.
My interest was recently peaked when being made aware of a number of
related sites committing abuse against a variety of brands; all quite
clearly in violation of copyrights and trademarks.
An example, for your consideration: messenger-download.info
After a little exploration it was quickly determined that these
cretins seek only to con victims out of credit card data with the
promise of illegal downloads for a fee.
Apparently these dbags have been at it for awhile.
They make it look like you're going to receive access to a legitimate
offering then they suck you in to freedownloadzone.com.
This, of course, pissed me off, so...off to the races.
A poke here, a tickle there, and voila.../etc/passwd...
--
Russ McRee
GCIH, GPEN, GCFA, CISSP
425-518-6998 cell
http://holisticinfosec.org
http://blog.holisticinfosec.org
------------------------------
Message: 7
Date: Mon, 8 Feb 2010 16:13:22 -0800
From: travis+ml-dailyd...@subspacefield.org
Subject: [Dailydave] secure priv-dropping code in python
To: dailydave@lists.immunitysec.com
Message-ID: <20100209001322.ga1...@subspacefield.org>
Content-Type: text/plain; charset="us-ascii"
Hey I wrote this code to safely and portably* drop permissions in
python a while back and just realized that people here might be
interested:
http://www.subspacefield.org/~travis/python/privilege/
[*] Caveat; OS-portable, not sure if it's portable between 32 and 64
bit arches yet. Need to think about (& test) Python c_uint size
vs sizeof(uid_t) on 64 bit arches.
Implements design from these papers:
http://www.cs.berkeley.edu/~daw/papers/setuid-usenix02.pdf
http://www.cs.berkeley.edu/~daw/papers/setuid-login08b.pdf
I also submitted a patch to python that implements setres[ug]id natively,
rather than having to load libc like I do in the code above. Not sure
what its status is, but general response was good.
--
In God We Trust; From Everyone Else, We Need Source Code.
My emails do not have attachments; it's a digital signature that your mail
program doesn't understand. | http://www.subspacefield.org/~travis/
If you are a spammer, please email j...@subspacefield.org to get blacklisted.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
Url :
http://lists.immunitysec.com/pipermail/dailydave/attachments/20100208/b63109c7/attachment-0001.pgp
------------------------------
Message: 8
Date: Tue, 09 Feb 2010 12:50:01 -0500
From: dave <d...@immunityinc.com>
Subject: [Dailydave] IE Protected Mode
To: dailyd...@lists.immunityinc.com
Message-ID: <4b71a049.5040...@immunityinc.com>
Content-Type: text/plain; charset=ISO-8859-1
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
So one thing we noticed when testing aurora_flash today on Windows 7 is
that, you can do this:
1. Own Windows 7 IE running as a normal user with Aurora_Flash
2. Run NTVDM exploit
3. Use Local/SYSTEM rights to do whatever you want.
Of course, step 2 won't work on a 64-bit Windows 7, and step 1 is not as
reliable as we'd like (the "aurora" part of "aurora_flash" can be a bit
tricky).
Nevertheless, it's a compelling demo when your customer says "But I'm on
Windows 7!". There's a tendency for "multi-layer defense" to coalesce
into one layer. I'm not sure what to call that, but it's pretty common.
Think "CLOUDBURST vs VMWare" and "Spender vs SELINUX" and all the other
similar protections that in many cases have no effect at all.
Another thing we're including in today's CANVAS release is our test
framework, so if you want you can automate testing against lots of VM's.
Basically, it starts them up, reverts them to a snapshot, sets up a
bunch of stuff to run the exploits, and then sees if they work, and then
shuts them down. You'd think with a heap overflow run like this that it
would work either 100% of the time or 0%, but the reality is, these
things can be affected by quantum tunnelling or something, and you get
them working row times in a row, and then failing ten times in a row.
- -dave
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAktxoEkACgkQtehAhL0gheo8MACdEGQ/vOGpt36PKJJz6nA8xmxP
vF8An1XeRtPZm9ShcWO0cjo+LhgUmK/C
=YMWP
-----END PGP SIGNATURE-----
------------------------------
Message: 9
Date: Tue, 9 Feb 2010 14:45:27 -0800
From: travis+ml-dailyd...@subspacefield.org
Subject: [Dailydave] analyzing Android
To: dailydave@lists.immunitysec.com
Message-ID: <20100209224527.gb1...@subspacefield.org>
Content-Type: text/plain; charset="us-ascii"
Been doing some analysis of Android.
The relevant links I've collected are here:
http://www.subspacefield.org/~travis/android.html
Should be enough for interested parties to get started.
Note that you don't need a physical device; the emulator is
high-fidelity, based on QEMU, and runs the same ARM binaries as the
phone. But you get root by default when shelling in. I'm impressed.
Included are links to native dropbear SSHd, and rsync, so you can
access the phone easily. Native compilation is easy, you cross-compile
with GCC for ARM and statically link against a normal libc.
--
In God We Trust; From Everyone Else, We Need Source Code.
My emails do not have attachments; it's a digital signature that your mail
program doesn't understand. | http://www.subspacefield.org/~travis/
If you are a spammer, please email j...@subspacefield.org to get blacklisted.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
Url :
http://lists.immunitysec.com/pipermail/dailydave/attachments/20100209/f48877fa/attachment.pgp
------------------------------
_______________________________________________
Dailydave mailing list
Dailydave@lists.immunitysec.com
http://lists.immunitysec.com/mailman/listinfo/dailydave
End of Dailydave Digest, Vol 55, Issue 3
****************************************
