[ News ] [ Paper Feed ] [ Issues ] [ Authors ] [ Archives ] [ Contact ]


..[ Phrack Magazine ]..
.:: Phrack Prophile on The PaX Team ::.

Issues: [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ] [ 16 ] [ 17 ] [ 18 ] [ 19 ] [ 20 ] [ 21 ] [ 22 ] [ 23 ] [ 24 ] [ 25 ] [ 26 ] [ 27 ] [ 28 ] [ 29 ] [ 30 ] [ 31 ] [ 32 ] [ 33 ] [ 34 ] [ 35 ] [ 36 ] [ 37 ] [ 38 ] [ 39 ] [ 40 ] [ 41 ] [ 42 ] [ 43 ] [ 44 ] [ 45 ] [ 46 ] [ 47 ] [ 48 ] [ 49 ] [ 50 ] [ 51 ] [ 52 ] [ 53 ] [ 54 ] [ 55 ] [ 56 ] [ 57 ] [ 58 ] [ 59 ] [ 60 ] [ 61 ] [ 62 ] [ 63 ] [ 64 ] [ 65 ] [ 66 ] [ 67 ] [ 68 ] [ 69 ] [ 70 ]
Current issue : #66 | Release date : 2009-11-06 | Editor : The Circle of Lost Hackers
IntroductionTCLH
Phrack Prophile on The PaX TeamTCLH
Phrack World NewsTCLH
Abusing the Objective C runtimenemo
Backdooring Juniper FirewallsGraeme
Exploiting DLmalloc frees in 2009huku
Persistent BIOS infectionaLS and Alfredo
Exploiting UMA : FreeBSD kernel heap exploitsargp and karl
Exploiting TCP Persist Timer Infinitenessithilgore
Malloc Des-Maleficarumblackngel
A Real SMM RootkitCore Collapse
Alphanumeric RISC ARM ShellcodeYYounan and PPhilippaerts
Power cell buffer overflowBSDaemon
Binary Mangling with Radarepancake
Linux Kernel Heap Tampering DetectionLarry H
Developing MacOS X Kernel Rootkitsghalen and wowie
How close are they of hacking your braindahut
Title : Phrack Prophile on The PaX Team
Author : TCLH
                             ==Phrack Inc.==

                 Volume 0x0d, Issue 0x42, Phile #0x02 of 0x11

|=----------------------------------------------------------------------=|
|=------------------------=[ PHRACK PROPHILE ON ]=----------------------=|
|=----------------------------------------------------------------------=|
|=------------------------------=[ pipacs ]=----------------------------=|
|=----------------------------------------------------------------------=|

|=---=[ Specifications

           Handle: pipacs
              AKA: PaX Team
    Handle origin: your pick between P. Howard and images.google.com :)
      Produced in: .hu
             Urlz: pax.grsecurity.net
        Computers: always a generation behind...
       Creator of: PaX
        Member of: PaX Team :)
         Projects: PaX
	    Codez: ntid
     Active since: 15+ years
   Inactive since: past few years

|=---=[ Favorites

	  Actors: Chaplin
	   Films: Versus
	 Authors: Gurdjieff
	   Books: Fire from within
	   Novel: Jonathan Livingston Seagull
	 Meeting: eclipse'99
	   Music: Radioaktivitaet, The light of the spirit
	 Alcohol: long island iced tea
	    Cars: Maserati
	   Foods: anything but 4 legs
	  I like: good beer & wine
       I dislike: all that bitter 'beer' down under :P


|=---=[ Your current life in a paragraph

	Working on some PHP/.net/js stuff for a SaaS startup, and generally
	tired of everything security related. Fortunately there's life beyond
	that :).

|=---=[ First contact with computers

	Despite the early 80's behind the iron curtain and COCOM restrictions,
	I somehow managed to get my hands on an ABC-80 during a summer camp.
	It was Z-80 and BASIC, but one had to start somewhere ;). Afterwards
	came a ZX-81, a Spectrum, etc, the usual stuff in those days.

|=---=[ Passions : What makes you tick

	Unsolved problems. Unsolvable problems.

|=---=[ Entrance in the underground

	I'm not sure I was ever part of the underground but let's just say that
	many of the smart people I met in the mid-90's would later end up in
	computer security as a necessary outgrowth of skills they acquired in
	reverse engineering. To me they're still the friends of 10+ years and
	there's nothing	particular about being part of the underground (ok,
	did i successfully ditch the question? :).

|=---=[ Which research have you done or which one gave you the most fun?

	It's of course PaX, especially some 6 years ago when spender and me
	were porting it to new CPUs while solving unsolvable problems (where's
	that NX bit on ppc32 again? :).

|=---=[ How you got started on low-level concepts?

	In the ZX Spectrum days I wanted to stop the clock in some game, so
	there I was learning Z-80 assembly and finding that pesky dec (hl).
	From then on it was lots of assembly coding for the Spectrum (still
	proud of my own turbo loader after all these years :) then later the
	Amiga (m68k) and finally the PC.

	Interestingly, I really hated the PC (x86) after the m68k but when
	I had to clean up after a virus infection (the first and only one I
	ever got :), I finally gave in and learned x86 as well and began to
	reverse engineer more stuff, particularly exe packers (ever since that
	virus incident I still have the habit of unpacking and looking at
	everything first). That then led to a never ending cat&mouse game
	between debuggers and anti-debugging techniques, so I had to eventually
	reverse	engineer and fix my choice of a debugger, SoftICE. That was a
	major undertaking in hindsight but it taught me a lot about CPU details
	that proved very useful in later years.

|=---=[ Thoughts on future of security enhancements?

	I think we'll see more of them as now there's very serious push in
	the commercial sector (mostly due to Microsoft) to research and
	develop practically useful techniques. There will be more tool chain
	enhancements and also more kernel and hypervisor level work to lock
	down various parts of the software stack and also to provide some
	level of self-protection.

	There will also be more work towards hardening parts of the client
	side userland that is both powerful and most exposed to attacks.
	Think web browsers, media players, etc, that all implement some form
	of programmable engines which represent the same kind of problems as
	runtime code generation (shellcode) did in the previous decades, just
	at a higher abstraction level. Whether techniques developed so far
	will be adaptable or not is an open question, but this problem needs
	to be addressed soon.

|=---=[ Short history of PaX?

	At around the time when the Y2K panic was settling down I got into
	a startup to develop a HIPS for windows. That didn't work out in
	the end for several reasons, but the idea stuck into my head and
	while enjoying the summer between two jobs, I somehow remembered
	what I had read about a year ago on IA-32 TLB hacking and I was set
	on the path. I talked to a few friends about it and we decided to
	do a windows version as that's what we were familiar with (speaking
	of kernel internals). This is also the reason for the 'team' in the
	name, even if the other guys dropped out soon afterwards to pursue
	other interests.

	The summer passed and I got a new job where linux was everywhere and
	one October weekend I sat down and figured I'd give it a try. Turned
	out that the first cut wasn't that hard and I was surprised that the
	new kernel booted without a hitch and worked as expected.

	Then came public disclosure day, something I had debated for some time
	but decided I wasn't going to go down the patent road. I still think
	it was the right decision, even if many people thought and still think
	I was a bit crazy to let this out for free :).

	The following years saw slow but steady development of various ideas,
	limited by my free time, (un)fortunately (depending on which side of
	the fence you are :). For a more precise timeline just look at the
	wikipedia article, I think my years spent in (sometimes voluntary)
	unemployment will clearly stand out :).

|=---=[ What future things are planned for PaX?

	I wish I could just even list them :), but having looked at my to-do
	list it seems I've got enough work left to fill more than a lifetime.

	So without any particular preference, here's a few ideas that I hope
	I can implement one of these days:

	Ret2libc prevention: this is something I'd written about 6 years ago
	but never got to implement it, and somewhat shamefully, the world at
	large failed to as well (save for MSR's Gleipnir project perhaps).
	I mean, all the effort people spent in the last decade on propolice/ssp
	could have equally been spent on solving this much more relevant and
	important problem...

	Kernel self-protection: the goal here is to solve the somewhat
	unsolvable problem of the kernel protecting itself from its own bugs.
	What is or isn't possible is something you'll have to wait and see :).

	More arch support: it would be nice if more CPU specific features could
	be ported to other archs beyond x86, in particular ARM (android, mobile
	phones) and MIPS (network gear) really need all the protection they can
	get.

	Virtualization support: whether it's a good idea or not from a security
	point of view, virtualization is here to stay and unfortunately quite a
	few of the existing kernel self-protection features are hard to handle
	in those environments. I'm not yet sure what concessions can be made
	here...

|=---=[ Personal general opinion about the underground

	I don't know much about it given how many years ago I lost most of my
	interest in computer security, but I can't help but note that the
	barrier of entry is set a lot higher than in the previous century.
	Couple that with vested new interests (both commercial, governmental
	and criminal, with unclear boundaries at times :P) in siphoning off
	all the knowledge and people in security and I can see no bright
	future for the kind of underground that there was before...

	I just hope that the spirit of not taking anything at face value,
	looking behind and beyond of what is already known will not die out in
	the younger generations and some of them will keep their independence
	for long enough to nurture underground outlets as this one :).

|=---=[ Memorable Experiences

	Meeting the internet in the early 90's when the whole country was
	connected on a 9.6 kbps line to Vienna.

	Downloading IDA 2.x in '94 and not knowing what to do with it at
	first (anyone remembers ReSource on the Amiga? :).

	Playing with SMM back in 1998, I keep wondering when Probe Mode gets
	'discovered' and hyped up as well :).

	Eclipse'99.

	That ADMcon.

	Being told by several native (english) speakers that I have a french
	accent :P.

	Seeing the AMD 'anti virus protection' ad on the London tube in the
	summer of 2004 and realizing I may have had something to do with it.

	2005, vomatron with a prince of Sri Lanka, you can blame PaX on him
	too.

	BAcon 06, the first and original one.

	Padocon.

	Teaching half the world to pronounce ege'szse'getekre (blame the lack
	of proper accents on Phrack mandated ASCII :P).

	Having to endure snoring from all kinds of people :).

|=---=[ Memorable people you have met

	People who worked on icedump.
	The wonderful team of Q.
	People who helped with PaX.
	The Padocon folks who got a tad bit drunk on palinka.

|=---=[ Memorable places you have been

	All over the world except Antarctica.

|=---=[ Things you are proud of

	Reverse engineering SoftICE to the point that some NuMega folks
	reportedly thought their src got stolen or something.

	Learning amd64 and porting a pure asm kernel driver to XP 64 RC and
	reverse engineering and circumventing PatchGuard (a year before
	Uninformed had published anything on it) all in 4 weeks while also
	handling an lkml flamewar and being jetlagged down under...

|=---=[ Things you are not proud of

	Some would say it's all the things I'm proud of :).

	Oh, and sorry for having held up this release, but life's just too
	busy...

|=---=[ Opinion about security conferences

	Too much hype over too little content. But then there're exceptions.

	Fortunately most are organized enough that presentations are available
	online with many academic confs being the exception, shame on them.
	Nevertheless, it seems that I still managed to collect over 16 GB of
	(security) conference material over the years so I guess the situation
	is not that bad. I wish I had time to read all that though :).

|=---=[ Opinion on Phrack Magazine 1985' ? 1995' ? 2005' ? '2009 ?

	1985: I wish we had had a phone line to begin with :)
	1995: the days when gopher was being taken over by http, and no
	      encryption in sight... anyway, I think p47 was the first issue I
	      got my hands on, and I didn't find it too interesting at the time,
	      sorry :)
	2005: that'd be p63 I guess (your version, that is :), a whole lot more
	      stuff, and finally beyond the 100th how-to-backdoor-linux kind of
	      article
	2009: I have yet to see, it didn't leak so far (kudos for the new team :)

|=---=[ What you would like to see published in Phrack ?

	More hardware related hacking, there're way too many gizmos out there
	these days to be ignored...

	More specific uses of computers, such as aviation, space, astronomy,
	particle physics, etc. There must be interesting things hiding there.

	More food-for-thought kind of articles, it's somehow got neglected...

|=---=[ Shoutouts to specific (group of) peoples

	The old folks from UCF and other groups, all the Q people and those I
	met through them, and basically everyone I drank a beer with :).
 
|=---=[ Flames to specific (group of) peoples

	It's all in the search engines already, for the better or worse :).

|=---=[ Quotes

	On some sunny day in July 2002 (t: Theo de Raadt):

<cloder> why can't you just randomize the base
<cloder> that's what PaX does
<t> You've not been paying attention to what art's saying, or you don't 
    understand yet, either case is one of think it through yourself.
<cloder> whatever

	Only to see poetic justice in August 2003 (ttt: Theo again):

<miod> more exactly, we heard of pax when they started bitching
<ttt> miod, that was very well spoken.

	More recently, a student contemplating doing research related to
	PaX/grsecurity:

<xxx> So Dr. Spafford essentially told me that it's better to work on something
      simpler than to try to do research that will save the world

|=---=[ Anything more you want to say 

	While most of the readers are undoubtedly living a computer dominated
	life, let me remind everyone that you can't have beer over the
	internet.  So go get out sometimes and maybe even invite the neighbour
	over. For this is what builds real relationships, not electronic
	substitutes.

--------[ EOF
[ News ] [ Paper Feed ] [ Issues ] [ Authors ] [ Archives ] [ Contact ]
© Copyleft 1985-2021, Phrack Magazine.