OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: Here's another glibc env. var.
From: Solar Designer (solarfalse.com)
Date: Thu May 25 2000 - 07:45:28 CDT

>
> > You're removing needed functionality to get around programming errors.
>
> No. I suggest to reduce functionality to discourage bad design. Complex
> security-hazard-prone code, including (but not limited to) user interface
> stuff, should be separated from code running with elevated privileges
> that should be really small, simple, and paranoid.

> > And I had to patch against 5.4.38 instead in order to be able to use
> > elm where it needed SGID mail.
>
> See above. :)

I fully agree that elm is broken and should be replaced totally (for
other reasons as well), but somehow I am still using it and I am not
alone. ;-(

> > I believe at least LC_CTYPE should be supported for SUID/SGID (LANG
> > and LC_ALL should probably be limited to the functionality of
> > LC_CTYPE if SUID/SGID),
>
> The other guy advocated LC_MESSAGES.

Well, LC_MESSAGES means almost everything is supported, so this can't
be a part of a restricted mode if we make one. I agree that there're
cases where full locale support in SUID/SGID applications is desired
(even though these applications are broken security-wise and probably
by other means as well) and that's why I'd like to see a nice way for
implementing libc options that wouldn't be user-controllable and
wouldn't require rebuilding.

> > but restricted to not allow known control characters.
>
> I'd prefer a fail-safe mode: restrict to known harmless characters.

I once again agree that this is the right approach in general, but in
this case we can't disallow non-official control characters, anyway,
even if some non-VTxxx terminal turns out to interpret them.

> > While we're on the topic, the ru_RU.KOI8-R locale in glibc 2.1.3
> > thinks '\x80' through '\x9f' are printable characters.
>
> This is correct. These characters are printable in KOI8 encoding (they
> put PC semigraphic chars there).

Yes, but that doesn't stop terminals from interpreting '\x9b'. ESC
has a defined look and feel ;-) as well, do we declare it printable?

Just did some testing with my vt420, set to "UPSS DEC Russian" (which
is essentially KOI8-R), 8-bit characters, and VT400 mode with 7-bit
controls (setting this to 8-bit controls breaks some functionality,
but doesn't affect the "exploit"). It does indeed interpret several
characters in the '\x80' to '\x9f' range (not only CSI).

I should arguably be using a separate locale for this terminal, but I
don't think there is one.

> > Perhaps there should also be an option to disable this, but it would
> > have to be read from a file or such, which has a performance impact.
> > Any suggestions?
>
> I think the performance penalty would be negligible compared to existing
> overhead (e.g. dynamic linking).

This simply makes it harder to advocate such an option.

Signed,
Solar Designer