[9fans] Plan 9 buffer overflow exploit explained in Phrack Volume 0x0b, Issue 0x3e, Phile #0x09 of 0x0f

[9fans] Plan 9 buffer overflow exploit explained in Phrack Volume 0x0b, Issue 0x3e, Phile #0x09 of 0x0f

[Vester Thacker]

Just in case some folks haven't read about it, an article was written about a
Plan9 exploit. The article can be found at http://phrack.unixchicks.com/
p62-0x09.txt

I found it disheartening, but interesting nonetheless. Comments?

-- Vester Thacker

Re: [9fans] Plan 9 buffer overflow exploit explained in Phrack Volume 0x0b, Issue 0x3e, Phile #0x09 of 0x0f

[Russ Cox]

He exploited a buffer overrun in his own program.
It would be more interesting if he exploited a buffer
overrun in some system program, preferably one that
listens to the network.  But then, he'd still be none.

Russ

Re: [9fans] Plan 9 buffer overflow exploit explained in Phrack Volume 0x0b, Issue 0x3e, Phile #0x09 of 0x0f

[Markus Friedl]

AFAIK, phrack 62 is fake, a hoax.

On Sat, Sep 20, 2003 at 02:55:37AM -0400, Russ Cox wrote:
> He exploited a buffer overrun in his own program.
> It would be more interesting if he exploited a buffer
> overrun in some system program, preferably one that
> listens to the network.  But then, he'd still be none.
>
> Russ

Re: [9fans] Plan 9 buffer overflow exploit explained in Phrack Volume 0x0b, Issue 0x3e, Phile #0x09 of 0x0f

[Dan Cross]

Wow; I haven't laughed _that_ hard in a *long* time.  I especially like
the last few paragraphs, and the part about him flunking his high-school
english class.

In terms of a technical reaction, the first thing that strikes me is:  We
have 51 system calls now?  Wow; we've porked up.  How many of those are for
compatability with the 3rd Edition?

	- Dan C.

Re: [9fans] Plan 9 buffer overflow exploit explained in Phrack Volume 0x0b, Issue 0x3e, Phile #0x09 of 0x0f

[Russ Cox]

i count 36 essential system calls, up from 35 in 2e.
basically fd2path is the only change.

4e essential:

#define	BIND		2
#define	CHDIR		3
#define	CLOSE		4
#define	DUP		5
#define	ALARM		6
#define	EXEC		7
#define	EXITS		8
#define	FAUTH		10
#define	SEGBRK		12
#define	OPEN		14
#define	SLEEP		17
#define	RFORK		19
#define	PIPE		21
#define	CREATE		22
#define	FD2PATH		23
#define	BRK_		24
#define	REMOVE		25
#define	NOTIFY		28
#define	NOTED		29
#define	SEGATTACH		30
#define	SEGDETACH		31
#define	SEGFREE				32
#define	SEGFLUSH	33
#define	RENDEZVOUS	34
#define	UNMOUNT		35
#define	SEEK		39
#define	FVERSION	40
#define	ERRSTR	41
#define	STAT	42
#define	FSTAT	43
#define	WSTAT	44
#define	FWSTAT	45
#define	MOUNT	46
#define	AWAIT	47
#define PREAD	50
#define PWRITE	51

2e essential:

#define	ERRSTR		1
#define	BIND		2
#define	CHDIR		3
#define	CLOSE		4
#define	DUP		5
#define	ALARM		6
#define	EXEC		7
#define	EXITS		8
#define FSESSION	9
#define	FAUTH		10
#define	FSTAT		11
#define SEGBRK		12
#define	MOUNT		13
#define	OPEN		14
#define	READ		15
#define	SEEK		16
#define	SLEEP		17
#define	STAT		18
#define	RFORK		19
#define	WRITE		20
#define	PIPE		21
#define	CREATE		22
#define	BRK_		24
#define	REMOVE		25
#define	WSTAT		26
#define	FWSTAT		27
#define	NOTIFY		28
#define	NOTED		29
#define SEGATTACH 	30
#define SEGDETACH 	31
#define SEGFREE   	32
#define SEGFLUSH	33
#define RENDEZVOUS	34
#define UNMOUNT		35
#define	WAIT		36

Re: [9fans] Plan 9 buffer overflow exploit explained in Phrack Volume 0x0b, Issue 0x3e, Phile #0x09 of 0x0f

[Dan Cross]

And presumably the rest are for binary compatibility with older (pre-4e)
systems?  Hmm....  That's a lot of compatibility to be carrying around.

	- Dan C.

Re: [9fans] Plan 9 buffer overflow exploit explained in Phrack Volume 0x0b, Issue 0x3e, Phile #0x09 of 0x0f

[William K. Josephson]

On Sat, Sep 20, 2003 at 01:49:56PM -0400, Dan Cross wrote:
> And presumably the rest are for binary compatibility with older (pre-4e)
> systems?  Hmm....  That's a lot of compatibility to be carrying around.

How else are you going to run mpm? ;-)

Re: [9fans] Plan 9 buffer overflow exploit explained in Phrack Volume 0x0b, Issue 0x3e, Phile #0x09 of 0x0f

[Dan Cross]

Funny you should mention that...  it's exactly what I was thinking of
in terms of NOT eliminating compatibility.  I suppose the obvious answer
would be to just recompile it with g++ or otherwise release it (mpm).

	- Dan C.

Re: [9fans] Plan 9 buffer overflow exploit explained in Phrack Volume 0x0b, Issue 0x3e, Phile #0x09 of 0x0f

[Russ Cox]

> Funny you should mention that...  it's exactly what I was thinking of
> in terms of NOT eliminating compatibility.  I suppose the obvious answer
> would be to just recompile it with g++ or otherwise release it (mpm).

it's not just mpm.  i can run almost every binary that has
ever been compiled on plan 9 (for my current architecture).
that's useful occasionally, and it's 100 lines of code to implement.
if you don't want to carry it around, you could chop it out
of your copy, but there are much bigger things you could drop
instead.

Re: [9fans] Plan 9 buffer overflow exploit explained in Phrack Volume 0x0b, Issue 0x3e, Phile #0x09 of 0x0f

[Dan Cross]

> it's not just mpm.  i can run almost every binary that has
> ever been compiled on plan 9 (for my current architecture).
> that's useful occasionally, and it's 100 lines of code to implement.
> if you don't want to carry it around, you could chop it out
> of your copy, but there are much bigger things you could drop
> instead.

Oh, I don't know; it depends on what the compatibility routines do.  If
they just marshall arguments around (for instance, dealing with the
widening of types and the like), that's one thing.  On the other hand,
if they represent entirely different implementations of common system
calls, such as in cases where semantics have changed and some amount of
compatibility with the old semantics was desired, that's another.  If
we find the system call table filling up with the latter, I'd say it's
time to start thinking about recompiling things that are usefully
brought forward and chopping out the compatibility stuff.  Yes, there
are bigger fish to fry, but if you can kill this one while it's still a
tadpole, it seems like a good idea.

That said, I'd note that some of the more interesting programs in,
e.g., 2nd edition are affected not by the lack or change in system
calls, but by fundamental changes in subsystems (ie, the introduction
of /dev/draw as a replacement for /dev/bitblt and friends, which
affects a number of things).

	- Dan C.

(Ps- I really do think it would be nice to get mpm out and give people
the opportunity to either rewrite it or recompile it with g++.)

Re: [9fans] Plan 9 buffer overflow exploit explained in Phrack Volume 0x0b, Issue 0x3e, Phile #0x09 of 0x0f

[Russ Cox]

> (Ps- I really do think it would be nice to get mpm out and give people
> the opportunity to either rewrite it or recompile it with g++.)

didn't rob post it a few years ago?

[9fans] mpm again

[Russ Cox]

> didn't rob post it a few years ago?

yes, yes he did.  february 2002.
/n/sources/extra/mpm.bundle has what he posted.

Re: [9fans] Plan 9 buffer overflow exploit explained in Phrack Volume 0x0b, Issue 0x3e, Phile #0x09 of 0x0f

[William K. Josephson]

On Sat, Sep 20, 2003 at 02:37:41PM -0400, Dan Cross wrote:
> (Ps- I really do think it would be nice to get mpm out and give people
> the opportunity to either rewrite it or recompile it with g++.)

Rob has posted the source before; I use it under Unix with
some frequency, in fact.

Re: [9fans] Plan 9 buffer overflow exploit explained in Phrack Volume 0x0b, Issue 0x3e, Phile #0x09 of 0x0f

[David Presotto]

[-- Attachment #1: Type: text/plain, Size: 317 bytes --]

There are actually on 48.  10 are there for backward compatibilit.

/sys/src/libc/9syscall/sys.h

Not much that wasn't there 3rd edition.  I'm looking at adding a passfd
thought my first attempt wasn't pretty.  Actually passfd was easy but
making it work across systems was a bit strained.  I'm working on that.

[-- Attachment #2: Type: message/rfc822, Size: 2495 bytes --]

From: Dan Cross <cross@math.psu.edu>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Plan 9 buffer overflow exploit explained in Phrack Volume 0x0b, Issue 0x3e, Phile #0x09 of 0x0f
Date: Sat, 20 Sep 2003 13:14:04 -0400
Message-ID: <200309201714.h8KHE4j24603@augusta.math.psu.edu>

Wow; I haven't laughed _that_ hard in a *long* time.  I especially like
the last few paragraphs, and the part about him flunking his high-school
english class.

In terms of a technical reaction, the first thing that strikes me is:  We
have 51 system calls now?  Wow; we've porked up.  How many of those are for
compatability with the 3rd Edition?

	- Dan C.

Re: [9fans] Plan 9 buffer overflow exploit explained in Phrack Volume 0x0b, Issue 0x3e, Phile #0x09 of 0x0f

[David Presotto]

[-- Attachment #1: Type: text/plain, Size: 70 bytes --]

Not much code, just syscall space.  We can probably nuke most of them.

[-- Attachment #2: Type: message/rfc822, Size: 2302 bytes --]

From: Dan Cross <cross@math.psu.edu>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Plan 9 buffer overflow exploit explained in Phrack Volume 0x0b, Issue 0x3e, Phile #0x09 of 0x0f
Date: Sat, 20 Sep 2003 13:49:56 -0400
Message-ID: <200309201749.h8KHnuj24873@augusta.math.psu.edu>

And presumably the rest are for binary compatibility with older (pre-4e)
systems?  Hmm....  That's a lot of compatibility to be carrying around.

	- Dan C.

Re: [9fans] Plan 9 buffer overflow exploit explained in Phrack Volume 0x0b, Issue 0x3e, Phile #0x09 of 0x0f

[I phantom]

markus@openbsd.org (Markus Friedl) wrote in message news:<20030920153514.GA25835@folly>...
> AFAIK, phrack 62 is fake, a hoax.
> 
> On Sat, Sep 20, 2003 at 02:55:37AM -0400, Russ Cox wrote:
> > He exploited a buffer overrun in his own program.
> > It would be more interesting if he exploited a buffer
> > overrun in some system program, preferably one that 
> > listens to the network.  But then, he'd still be none.
> > 
> > Russ

If you had actually bothered to read the introduction you would know
that
Phrack 62 is not fake but merely a change of direction. But actually
reading..... (a zine, documentation, literature, openssh code) is 2
much to expect from anyone@openbsd.org. To everyone else on this list,
I apologize.