[9fans] Plan 9 (in)security

[9fans] Plan 9 (in)security

[Mike Haertel]

While writing a small Plan 9 file server tonight, I got to thinking
about various exceptional conditions that the server might have to
deal with, for example will the server ever see walks to ".", or
will the kernel handle those for me?

Then it hit me that a robustly written 9P server shouldn't depend
on its client being the well-behaved Plan 9 kernel.  At least, not
if it's going to be accessible via the network.  There is no
guarantee that your remote client is, in fact, a real Plan 9 kernel.

This led to wondering about what kind of input validation
existing Plan 9 servers do.  One obvious thing is making sure
that names that are required to be nul-terminated strings of
length NAMELEN-1 or less do, in fact, meet these requirements.

Well, it turns out that convM2S() doesn't even enforce this.  It
uses memmove() to move exactly NAMELEN bytes from the input buffer
to the Fcall structure--whether or they contain a nul-terminated
string or anything else.  It won't overrun its destination Fcall
structure, but a clever attacker could probably arrange for data
to be written into the Fcall structure that might later cause a
file server using a strcpy() family function to go out of bounds
and do who knows what.  A similar caveat applies to convM2D().
For example, you might be able to crash or corrupt a file server
by sending a wstat request in which the name, uid, gid, and perhaps
following fields all contained no zero bytes.

I'm sure there are fancier attacks; these just struck me as
immediately obvious.  9P servers will not be secure unless they
are written to behave sanely in the presence of an arbitrarily
badly-behaved client.  Unfortunately this would seem to make writing
servers a good deal more difficult, and one of the advantages of
Plan 9 is supposed to be that writing file servers is a relatively
lightweight undertaking.  Perhaps additional library support can
help with this problem.

Re: [9fans] Plan 9 (in)security

[Alexander Viro]

On Sat, 26 May 2001, Mike Haertel wrote:

> Well, it turns out that convM2S() doesn't even enforce this.  It
> uses memmove() to move exactly NAMELEN bytes from the input buffer
> to the Fcall structure--whether or they contain a nul-terminated
> string or anything else.  It won't overrun its destination Fcall
> structure, but a clever attacker could probably arrange for data
> to be written into the Fcall structure that might later cause a
> file server using a strcpy() family function to go out of bounds
> and do who knows what.  A similar caveat applies to convM2D().
> For example, you might be able to crash or corrupt a file server
> by sending a wstat request in which the name, uid, gid, and perhaps
> following fields all contained no zero bytes.

Ehh... How about
                        ni = BGLONG(a+5);
                        font->fchar = malloc(ni*sizeof(FChar));
                        if(font->fchar == 0)
                                error("no memory for font");
                        memset(font->fchar, 0, ni*sizeof(FChar));
                        font->nfchar = ni;
                        font->ascent = a[9];

in devdraw.c? ni is received from user, sizeof(FChar) > 1, no sanity checks
on ni. Anyone who wouldn't see why that code is b0rken? And yes, it's
panicable - several lines below we have
                        ci = BGSHORT(a+9);
                        if(ci >= font->nfchar)
                                error(Eindex);
                        drawrectangle(&r, a+11);
                        drawpoint(&p, a+27);
                        memdraw(font->image, r, src, p, memopaque, p);
                        fc = &font->fchar[ci];
                        fc->minx = r.min.x;
IOW, have ni = ~0U / sizeof(FChar) + 42,  then ci = 69 and enjoy memory
corruption.

OK, it's not a security hole - you'd need to have access to /dev/draw on
CPU server to screw somebody else. However, having write(2) panicing the
box is a Bad Thing(tm).

Furrfu... It's not like that was something new. malloc(foo*sizeof(bar))
can return non-NULL and allocate less than array of foo elements - just
have the product slightly above the UINT_MAX.

Re: [9fans] Plan 9 (in)security

[Mike Haertel]

>OK, it's not a security hole - you'd need to have access to /dev/draw on
>CPU server [...]

I agree that there are local security holes and they're bad, however
network security holes are lots worse.

I just wanted to bring attention to the fact that many if not all
of the networkable 9p servers seem to be horrendously insecure,
and since some of them will allow anonymous attach, any Plan 9
server with exported filesystems is vulnerable to a sufficiently
clever attacker.

I constantly see people portscanning my systems, script kiddies
running well-known Linux attacks and who knows what else (it helps
to run a less-popular OS :-).  And I am not even an interesting
target (low bandwidth link, no web site, nothing interesting on my
systems, etc).  I shudder to imagine the number and variety of
attacks the "interesting" sites must get.  It's a jungle out there.

Re: [9fans] Plan 9 (in)security

[Alexander Viro]

On Sat, 26 May 2001, Mike Haertel wrote:

> >OK, it's not a security hole - you'd need to have access to /dev/draw on
> >CPU server [...]
> 
> I agree that there are local security holes and they're bad, however
> network security holes are lots worse.

If you accept requests from the outside. Sloppy code != security hole and
it is bad regardless of the exploit potential. It's a breeding ground for
bugs that are annoying and hard to find.

The thing being, most of that stuff can be found by grep. And if you dig
around you are going to see something bogus that is really worth fixing
regardless of the chances to get that particular bug exploited. Usually -
bad interface...

By the way, why on the Earth number of characters in font is passed as 32bit
value when you can set glyphs only for characters with numbers that fit
into 16 bits?

Re: [9fans] Plan 9 (in)security

[Lucio De Re]

On Sat, May 26, 2001 at 04:23:15PM -0700, Mike Haertel wrote:
[ ... ]
> attacks the "interesting" sites must get.  It's a jungle out there.

Please, let's be politically correct here.  In the jungle (or at least
the savannah that I am familiar with) there is no gratuitous attack by
predator on prey (nevermind the reverse).  Human criminal behaviour
does not resemble the wild at all!

++L

Re: [9fans] Plan 9 (in)security

[Dan Cross]

In article <20010702181031.EECB9199E1@mail.cse.psu.edu> you write:
>Obviously we should not set a fixed character size, like 256 bits,
>but migrate to a variable length encoding, where the first 16 bits
>describes the length of the character.

I'm not sure that 16 bits is sufficient.  You know, it's like,
restrictive and stuff.  Better make the length be 256 bits.

>HTH.  HAND.

PCMCIA.

	- Dan C.

Re: [9fans] Plan 9 (in)security

[David Gordon Hogan]

>>At 256 bits per character I think xml is an excellent idea.
>
>Perpetuating the joke, I know, but I have a question.
>
>If one is going to represent the character set using XML, then
>how does one represent the characters which make up the XML?
>
>Oh, I know, using 7 bit ASCII?
>
>Wouldn't it be so much easier if we were still using the PDP-10,
>which had variable size bytes, up to 36 bits in size?

Obviously we should not set a fixed character size, like 256 bits,
but migrate to a variable length encoding, where the first 16 bits
describes the length of the character.

HTH.  HAND.

Re: [9fans] Plan 9 (in)security

[Sam Ducksworth]

we could have a style sheet for every character. :-)

On Mon, 2 Jul 2001, Sape Mullender wrote:

> At 256 bits per character I think xml is an excellent idea.
>

--sam

Re: [9fans] Plan 9 (in)security

[Dan Cross]

In article <20010702150244.CBEF9199E3@mail.cse.psu.edu> you write:
>At 256 bits per character I think xml is an excellent idea.

Perpetuating the joke, I know, but I have a question.

If one is going to represent the character set using XML, then
how does one represent the characters which make up the XML?

Oh, I know, using 7 bit ASCII?

Wouldn't it be so much easier if we were still using the PDP-10,
which had variable size bytes, up to 36 bits in size?

	- Dan C.

Re: [9fans] Plan 9 (in)security

[Sape Mullender]

At 256 bits per character I think xml is an excellent idea.

Re: [9fans] Plan 9 (in)security

[rob pike]

> I'm not sure 16 bytes is enough to code up the header.
> You did mean it to be in xml?

Don't be stupid.

-rob

Re: [9fans] Plan 9 (in)security

[George Michaelson]

  > Why stop at 64 bits per character? Why not go for 256, a 16x16
  > dot matrix of the ISO image for the character.  Perhaps with a
  > 16-byte header with special information such as case, dialect,
  > diacritical marks, etc.
  >
  > -rob

Stop at 128. Then IPv6 addresses will all be printed as a single glyph.

I hope mine are in sanskrit.

-George

Re: [9fans] Plan 9 (in)security

[nigel]

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

I'm not sure 16 bytes is enough to code up the header.
You did mean it to be in xml?


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

From: "rob pike" <rob@plan9.bell-labs.com>
To: <9fans@cse.psu.edu>
Subject: Re: [9fans] Plan 9 (in)security
Date: Mon, 2 Jul 2001 07:56:46 -0400
Message-ID: <0a0a01c102ee$135823e0$41734e81@oemcomputer>

Why stop at 64 bits per character? Why not go for 256, a 16x16
dot matrix of the ISO image for the character.  Perhaps with a
16-byte header with special information such as case, dialect,
diacritical marks, etc.

-rob

Re: [9fans] Plan 9 (in)security

[rob pike]

Why stop at 64 bits per character? Why not go for 256, a 16x16
dot matrix of the ISO image for the character.  Perhaps with a
16-byte header with special information such as case, dialect,
diacritical marks, etc.

-rob

Re: [9fans] Plan 9 (in)security

[Jim Choate]

Don't simply re-create the errors of the past. Plan for the future.

Don't futz around with 64k of char, go for something like 32 bits or even
64 so that even in the future there won't be a significant effect as the
languages we use grow.

On Mon, 2 Jul 2001 okamoto@granite.cias.osakafu-u.ac.jp wrote:

> This is a multi-part message in MIME format.
> --upas-nuiiuxxrfozmxljuvcjoshbuyt
> Content-Disposition: inline
>
> Some says we need up to 60k chars for Japanese.   However, I must say
> I don't know such huge number of Kanji which eceeds my memory capacity.
> Most of 64k chars may be in very limited use such in some ancient documents
> etc.  :-)  If "computer" must deal with all of those documents, yes, we may have
> to have 64k chars...
>
> The 16 bit limits will meet problem, in practical, to write person's name, some
> of which are named using wrong Kanji when all Japanese were permitted
> to have their own family name about 150 years ago.  ^_^  Now, we cannot say
> it's wrong anymore. :-)


 --
    ____________________________________________________________________

            Whereof one cannot speak, thereof one must be silent.

                                      Ludwig Wittgenstein

       The Armadillo Group       ,::////;::-.          James Choate
       Austin, Tx               /:'///// ``::>/|/      ravage@ssz.com
       www.ssz.com            .',  ||||    `/( e\      512-451-7087
                           -====~~mm-'`-```-mm --'-
    --------------------------------------------------------------------

Re: [9fans] Plan 9 (in)security

[okamoto]

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

Some says we need up to 60k chars for Japanese.   However, I must say
I don't know such huge number of Kanji which eceeds my memory capacity.
Most of 64k chars may be in very limited use such in some ancient documents
etc.  :-)  If "computer" must deal with all of those documents, yes, we may have
to have 64k chars...

The 16 bit limits will meet problem, in practical, to write person's name, some
of which are named using wrong Kanji when all Japanese were permitted
to have their own family name about 150 years ago.  ^_^  Now, we cannot say
it's wrong anymore. :-)

Sorry, this is off topic.

Kenji


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

From: "Boyd Roberts" <boyd@fr.inter.net>
To: <9fans@cse.psu.edu>
Subject: Re: [9fans] Plan 9 (in)security
Date: Fri, 29 Jun 2001 23:08:26 +0200
Message-ID: <001f01c100df$a4274ab0$c0b7c6d4@SOMA>

> Actually that is highly debatable -- it depends on the requirement.
> For a "rune" or wchar_t, since 16 bits are not enough to provide
> the required functionality, 32 bits is the obvious choice

iirc chinese (mandarin) has some 60k chars.  not that they're
all used, but for completness's sake yer gonna need 32 bits.

btw: to survive in japan you need ~2k chars, but most newspapers
     get by with ~6k.

Re: [9fans] Plan 9 (in)security

[Boyd Roberts]

> Actually that is highly debatable -- it depends on the requirement.
> For a "rune" or wchar_t, since 16 bits are not enough to provide
> the required functionality, 32 bits is the obvious choice

iirc chinese (mandarin) has some 60k chars.  not that they're
all used, but for completness's sake yer gonna need 32 bits.

btw: to survive in japan you need ~2k chars, but most newspapers
     get by with ~6k.

Re: [9fans] Plan 9 (in)security

[Douglas A. Gwyn]

Alex Danilo wrote:
> So, yes 16 bits is not enough.  However 32 bit representations are
> discouraged - UTF16 is the way to go if you have to leave UTF8.

Actually that is highly debatable -- it depends on the requirement.
For a "rune" or wchar_t, since 16 bits are not enough to provide
the required functionality, 32 bits is the obvious choice.  UTF16
encodes some characters as 2 consecutive units, which is foreign
to the notion of rune or wide character.

Re: [9fans] Plan 9 (in)security

[Alex Danilo]

The two 16-bit words are for the surrogate area.
Unicode 3.1 is out - and there are 44,496 new characters, giving 94,140
total glyphs.
So, yes 16 bits is not enough.  However 32 bit representations are
discouraged - UTF16
is the way to go if you have to leave UTF8.

Alex

"Douglas A. Gwyn" wrote:

> Richard Elberger wrote:
> > ...  Perhaps once it is all catalogued and
> > accepted into unicode, 16 bits will not be enough.
>
> 16 bits was never enough, and currently the Windows world
> is scrambling to change from UCS-2 (old "16-bit Unicode")
> to UTF-16, which occasionally uses two 16-bit words for
> certain characters.  This is an active topic of discussion
> in the WG14 reflector.

Re: [9fans] Plan 9 (in)security

[Douglas A. Gwyn]

Richard Elberger wrote:
> ...  Perhaps once it is all catalogued and
> accepted into unicode, 16 bits will not be enough.

16 bits was never enough, and currently the Windows world
is scrambling to change from UCS-2 (old "16-bit Unicode")
to UTF-16, which occasionally uses two 16-bit words for
certain characters.  This is an active topic of discussion
in the WG14 reflector.

RE: [9fans] Plan 9 (in)security

[rob pike]

> But if the limit in the
> current implementation (0xFFFF -- has anyone heard any new developments
> here) needs to be extended -- maybe this makes the system call more flexible
> for the future? 

The limit he's referring to is for a `subfont', which is a subblock of a whole font,
typically for example the Latin-1 or Greek subblock.  Unless I'm mistaken,
the only place the 16 bit limit comes in is the definition of Rune as ushort,
which is in principle at least easy to fix.

-rob

RE: [9fans] Plan 9 (in)security

[Richard Elberger]

I don't know if you're talking about unicode work here (I am suspecting you
are).  As you probably know, the unicode folks haven't even catalogued all
the glyphs/scripts in existence yet in unicode -- heck, Ethiopic just
recently made it in not too long ago.  Perhaps once it is all catalogued and
accepted into unicode, 16 bits will not be enough.  But if the limit in the
current implementation (0xFFFF -- has anyone heard any new developments
here) needs to be extended -- maybe this makes the system call more flexible
for the future? Don't know.
http://www.unicode.org/unicode/standard/unsupported.html
Even if obsolete, they will eventually be in unicode to record original
scripts digitally (instead of scanning and deriving some information from a
document and plugging the info in a property sheet so search) -- which imo
would be cool.

-- rich

>-----Original Message-----
>From: 9fans-admin@cse.psu.edu [mailto:9fans-admin@cse.psu.edu]On Behalf
>Of rob pike
>Sent: Sunday, 27 May 2001 4:27 p.m.
>To: 9fans@cse.psu.edu
>Subject: Re: [9fans] Plan 9 (in)security
>
>
>> By the way, why on the Earth number of characters in font is
>passed as 32bit
>> value when you can set glyphs only for characters with numbers that fit
>> into 16 bits?
>
>Professional courtesy.
>
>-rob
>
>

Re: [9fans] Plan 9 (in)security

[rob pike]

> By the way, why on the Earth number of characters in font is passed as 32bit
> value when you can set glyphs only for characters with numbers that fit
> into 16 bits?

Professional courtesy.

-rob

Re: [9fans] Plan 9 (in)security

[Russ Cox]

> I just wanted to bring attention to the fact that many if not all
> of the networkable 9p servers seem to be horrendously insecure,
> and since some of them will allow anonymous attach, any Plan 9
> server with exported filesystems is vulnerable to a sufficiently
> clever attacker.

I think you exaggerate here.  Most of the 9P servers
do no authentication whatsoever, but those aren't 
listening to the network.  Exportfs listens to the
network, and it requires authentication.  Most of
the file servers don't matter from a security point
of view, any more than cat matters.  Wiki also listens
to the network, but that was written with the 9P
library, which is more demanding of its input.
Further, the specific bug you mentioned (conv?2?)
is corrected in the interface for the new 9P protocol.

Russ

Re: [9fans] Plan 9 (in)security

[Alexander Viro]

On Sat, 26 May 2001 jmk@plan9.bell-labs.com wrote:

> On Sat May 26 18:48:27 EDT 2001, viro@math.psu.edu wrote:
> ...
> > Furrfu... It's not like that was something new. malloc(foo*sizeof(bar))
> > can return non-NULL and allocate less than array of foo elements - just
> > have the product slightly above the UINT_MAX.
> > 
> 
> Furrfu?

Look at the context. Or rot13 if you are curious about etimology.

> UINT_MAX? What are those?
/sys/include/ape/limits.h:#define UINT_MAX   0xffffffffU

In other words, maximal possible value of unsigned int. Actually, ULONG_MAX
might be more accurate.

Re: [9fans] Plan 9 (in)security

[jmk]

On Sat May 26 18:48:27 EDT 2001, viro@math.psu.edu wrote:
...
> Furrfu... It's not like that was something new. malloc(foo*sizeof(bar))
> can return non-NULL and allocate less than array of foo elements - just
> have the product slightly above the UINT_MAX.
> 

Furrfu? UINT_MAX? What are those?