Date: Thu, 12 Apr 2012 21:36:40 -0400
From: Brad Spengler <spender@grsecurity.net>
To: alpine-devel@lists.alpinelinux.org
Subject: [alpine-devel] [announce] Sonnet's Swan Song
Message-ID: <20120413013640.GA29559@grsecurity.net>
Precedence: list
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="FCuugMFkClbJLl1L"
Content-Disposition: inline
User-Agent: Mutt/1.5.18 (2008-05-17)


--FCuugMFkClbJLl1L
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Such big balls you're trotting around there William (whoever you are).

Tonight I'll teach you an important lesson that I hope will be
instrumental in your future Internet career: when you speak with
authority about a subject on a public list, actually have some shred of
a clue what you're talking about.  Throwing around concepts you clearly
do not comprehend doesn't count.  In the immortal words of Jesus=20
Quintana, "You might fool the fucks in the league office, but you don't=20
fool Jesus."

Since it seems at least one person already fell for the lies from this=20
charlatan, I'll expose each one.

William "Charlatan" Pitcock demonstrates ASLR ignorance:
> This is false. The fact that the distribution is compiled with PIE is
> why many known exploits fail. The fact that binaries are compiled
> with PIE allows the ASLR code (either in Linux itself or provided by
> PaX) to randomize specific segment addresses in a binary. ASLR is the
> reason why ret2libc attacks are not successful.

What exploits?  Like local exploits that only have to be run more times
to succeed against vanilla ASLR?  That's not security.  If you read the
PaX documentation on ASLR (which it seems you need to re-read about 20
more times, along with the rest of the PaX documentation) then you would
know an anti-bruteforcing component is needed for ASLR to be effective
against respawning daemons and especially local applications.  You would
also know vanilla Linux provides no such thing.  You would also know
about the dozen or so local ASLR infoleaks that have existed in vanilla
Linux that were fixed in grsecurity, even ones that still exist despite
grsecurity's source being open to all!

William "Charlatan" Pitcock demonstrates MPROTECT ignorance:
> Now for a discussion about PaX mprotect.

Yes, please educate me on this topic!

> This part is actually somewhat useful: it ensures that badly written
> programs do not successfully request mprotect(..., PROT_WRITE |
> PROT_EXECUTE) by ensuring that PROT_EXECUTE is dropped or forbidden by
> mprotect() with errno=3DEPERM. However, this part can be easily written
> in a way where it is suitable for inclusion in the mainstream kernel
> and is very trivial to write. It also ensures that the stack can
> never be PROT_EXECUTE as a side-effect, also useful except in cases of
> trampoline, where you have programs with PT_GNU_STACK marking or PaX
> equivilant.

This demonstrates a very naive understanding of PAX_MPROTECT.  What
PAX_MPROTECT does is prevent the introduction of runtime-generated code
by ensuring, not a simple W^X in mprotect flags like you claim, but
also (as an example) the inability to take a previously writable mapping
and make it RX at a later time.  That the stack cannot be made
executable is not a side-effect, but one realization of the design.  It
was not "trivial" -- certainly not on sparc64 where the PLT is RWX and
requires emulation.  Your descriptions simply reflect your own naivety.
MPROTECT is still useful in the case of trampolines (that's why there's
a feature for their emulation).  PaX also ignores PT_GNU_STACK (see the
override code in load_elf_binary()) , but you already knew that right?

William "Charlatan" Pitcock demonstrates MPROTECT ignorance (part 2):
> However, there is a better approach to handling W^X

http://cdn.memegenerator.net/instances/400x/18434869.jpg

> which is just to automatically drop PROT_EXECUTE anytime PROT_WRITE is
> requested (and also the reverse). This provides the same security and
> is more compatible with virtual machines like Jaegermonkey, V8 and
> luajit. This is the approach as taken by OpenBSD, and coincidentally
> is partially implemented in modern Linux kernels. Some further
> protection by default is desirable here, but not really important in
> terms of defeating vulnerabilities.

This does *not* provide the same security.  In fact, in your second
sentence you specifically demonstrate that it doesn't provide the same
security where you list a bunch of JIT engines your "great idea" is
compatible with.  What's JIT again?  Oh, right, run-time code generation.
And what was the whole point of PAX_MPROTECT?  Go back and read the
documentation.  Sure, PAX_MPROTECT isn't really desirable -- I mean,
look at Windows.  Payloads there for the past 5 years definitely haven't
focused on achieving arbitrary code execution via VirtualProtect, right?
And it's so much more difficult to achieve if you do the VirtualProtect
RX after memcpying into the writable buffer!

William "Charlatan" Pitcock demonstrates MPROTECT ignorance (part 3):
> - using the CS register to emulate an NX-bit on legacy x86 platforms:
This isn't part of PAX_MPROTECT.  Again, you knew this of course!

> This part is entirely worthless, defeating the NX-bit emulation is
> trivial if you know what you're doing due to the limitations in the
> way the CS register works. To put it simply, the CS register defines
> the highest possible address of executable code. In other words, it
> should always be higher than ELF_LOAD_BASE, and should always be the
> size of .text.

Here you again demonstrate your brilliance.  It's almost as if you
read something I wrote in 2003 about exec-shield and then changed it in
your mind to something about PaX.  Nevermind that though, you were too
busy throwing around concepts you don't understand.  You see, PaX in
PAGEEXEC mode on systems that lack NX support uses segmentation purely
for increasing performance -- it provides the same protection as
PAGEEXEC did before the code limit tracking was introduced: per-page
non-executable pages.  It is never more coarse grained.  There are no
surprises like with exec-shield where the whole address space
silently becomes executable.  But I know you know this, because you've
bloviated on the subject on a public mailing list.

> However, when you need mprotect(..., PROT_EXECUTE) then the CS
> register has to be modified to point to the end of your memory mapping
> you're marking PROT_EXECUTE. When *that* happens, everything between
> ELF_LOAD_BASE and the end of your PROT_EXECUTE mapping is now
> executable, including any mappings that lay before it. ASLR helps
> against this a little, because mmap() mappings are at randomized
> addresses, but in reality with the CS segment, the ASLR actually makes
> this worse.

Wrong again -- same reasons as above.  We're talking about PaX,
remember?

William "Charlatan" Pitcock completes with his coup de grace:
> Regarding ASLR itself, I suspect PaX ASLR to be actually more weak
> than the default Linux ASLR with randomize_va_space=3D2. Thusly,
> there's not really any benefit to using PaX.

If only there were a way to "test" the ASLR strength of "PaX".  If there
were, we could surely perform such a test and compare it against a
vanilla kernel.  All we need is to think of a name to call such a
program...

Someone stick a fork in you, you're done.

-Brad

--FCuugMFkClbJLl1L
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAk+HgygACgkQmHm2SUJF1GrvowCgh2sUhCdHpIzuMzEcOLSqVi3/
5jsAnijkMxprpGId50BIPPqVBLwcj3bT
=v51Q
-----END PGP SIGNATURE-----

--FCuugMFkClbJLl1L--


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---