9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* Re: [9fans] Plan 9 (in)security
@ 2001-07-02 15:02 Sape Mullender
  2001-07-02 15:52 ` Dan Cross
  2001-07-02 16:24 ` Sam Ducksworth
  0 siblings, 2 replies; 26+ messages in thread
From: Sape Mullender @ 2001-07-02 15:02 UTC (permalink / raw)
  To: 9fans

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


^ permalink raw reply	[flat|nested] 26+ messages in thread
* Re: [9fans] Plan 9 (in)security
@ 2001-07-02 18:10 David Gordon Hogan
  2001-07-02 19:09 ` Dan Cross
  0 siblings, 1 reply; 26+ messages in thread
From: David Gordon Hogan @ 2001-07-02 18:10 UTC (permalink / raw)
  To: 9fans

>>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.



^ permalink raw reply	[flat|nested] 26+ messages in thread
* Re: [9fans] Plan 9 (in)security
@ 2001-07-02 12:01 nigel
  2001-07-02 12:05 ` George Michaelson
  2001-07-02 12:07 ` rob pike
  0 siblings, 2 replies; 26+ messages in thread
From: nigel @ 2001-07-02 12:01 UTC (permalink / raw)
  To: 9fans

[-- 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


^ permalink raw reply	[flat|nested] 26+ messages in thread
* Re: [9fans] Plan 9 (in)security
@ 2001-07-02  1:38 okamoto
  2001-07-02  2:03 ` Jim Choate
  0 siblings, 1 reply; 26+ messages in thread
From: okamoto @ 2001-07-02  1:38 UTC (permalink / raw)
  To: 9fans

[-- 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.


^ permalink raw reply	[flat|nested] 26+ messages in thread
* RE: [9fans] Plan 9 (in)security
@ 2001-05-27 15:00 rob pike
  0 siblings, 0 replies; 26+ messages in thread
From: rob pike @ 2001-05-27 15:00 UTC (permalink / raw)
  To: 9fans

> 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



^ permalink raw reply	[flat|nested] 26+ messages in thread
* Re: [9fans] Plan 9 (in)security
@ 2001-05-27  4:27 rob pike
  2001-05-27  6:43 ` Richard Elberger
  0 siblings, 1 reply; 26+ messages in thread
From: rob pike @ 2001-05-27  4:27 UTC (permalink / raw)
  To: 9fans

> 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



^ permalink raw reply	[flat|nested] 26+ messages in thread
* Re: [9fans] Plan 9 (in)security
@ 2001-05-27  0:52 Russ Cox
  0 siblings, 0 replies; 26+ messages in thread
From: Russ Cox @ 2001-05-27  0:52 UTC (permalink / raw)
  To: 9fans

> 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


^ permalink raw reply	[flat|nested] 26+ messages in thread
* Re: [9fans] Plan 9 (in)security
@ 2001-05-26 23:02 jmk
  2001-05-26 23:22 ` Alexander Viro
  0 siblings, 1 reply; 26+ messages in thread
From: jmk @ 2001-05-26 23:02 UTC (permalink / raw)
  To: 9fans

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?


^ permalink raw reply	[flat|nested] 26+ messages in thread
* [9fans] Plan 9 (in)security
@ 2001-05-26 19:54 Mike Haertel
  2001-05-26 22:47 ` Alexander Viro
  0 siblings, 1 reply; 26+ messages in thread
From: Mike Haertel @ 2001-05-26 19:54 UTC (permalink / raw)
  To: 9fans

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.


^ permalink raw reply	[flat|nested] 26+ messages in thread

end of thread, other threads:[~2001-07-02 19:09 UTC | newest]

Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-07-02 15:02 [9fans] Plan 9 (in)security Sape Mullender
2001-07-02 15:52 ` Dan Cross
2001-07-02 16:24 ` Sam Ducksworth
  -- strict thread matches above, loose matches on Subject: below --
2001-07-02 18:10 David Gordon Hogan
2001-07-02 19:09 ` Dan Cross
2001-07-02 12:01 nigel
2001-07-02 12:05 ` George Michaelson
2001-07-02 12:07 ` rob pike
2001-07-02  1:38 okamoto
2001-07-02  2:03 ` Jim Choate
2001-07-02 11:56   ` rob pike
2001-05-27 15:00 rob pike
2001-05-27  4:27 rob pike
2001-05-27  6:43 ` Richard Elberger
2001-05-29  9:17   ` Douglas A. Gwyn
2001-06-29  9:23     ` Alex Danilo
2001-06-29 13:57       ` Douglas A. Gwyn
2001-06-29 21:08         ` Boyd Roberts
2001-05-27  0:52 Russ Cox
2001-05-26 23:02 jmk
2001-05-26 23:22 ` Alexander Viro
2001-05-26 19:54 Mike Haertel
2001-05-26 22:47 ` Alexander Viro
2001-05-26 23:23   ` Mike Haertel
2001-05-27  1:40     ` Alexander Viro
2001-05-28  4:40     ` Lucio De Re

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).