happenings last night

elaine forbes elaine at fwsystems.com
Fri Feb 14 10:41:46 GMT 2003


On 13 Feb 2003 01:01:13 +0100 (unchecked - local sync NTPstrat4)
Auke Kok <auke.kok at planet.nl> did inscribe thusly:

> 
> 
> sorry for the lengthy text, but please read along if you were not
> there:

Sounds great, here are the things I've been generally concerned about
with lunar the way it stands.

Using the shell, especially with all the  `cmd $ARG` things we do is 
giving the semi-trusted data to a root-shell. The trust is that non of
our devs will embed shell metas into a module or url. -- I'd just rather
not do it.

Specifically I looked at this when I needed to develop a tracking system
for csm and found that urls formed http://host/data?var=value breaks a
number of things in the scripts.

I think tchan has (probably correctly) suggested that URNs are more
appropriate for the moonbase -- I'm going to belay that for the moment.


Ok so this is at some level a security issue, It'd be trivially easy
for any lunar developer to put a root exploit into a module -- while I
don't think any of us would do that, and the CVS logs would make
covering tracks difficult, I'd still rather this not be an issue.
 
As a second-level thing, it is possible (I'm *not* saying likely) that a
source-site could trick a lunar developer into using urls that would
exploit our shell scripts.

I haven't found any 'second-level' ways to exploit this -- that is aside
from the install-scripts could a source-site convince the lunar scripts
to execute atacker-chosen code, while maintaining innocent-looking urls.
However I'm not sure it can't be done.


Fixing

Lunar2
One way (and I think the better way) to fix this is to move to a
'stronger' programming language. lunar2 in ruby will give us both the
strength of perl style tainting to prevent data from ever being allowed
into a shell, as well as a better solution to dropping privelige.



Lunar bash
What's at hand now, dropping privs in bash has at least a few gotchas.

1. su only inherits persistent variables (e.g. export) so we can't
simply run 
...
su unprivuser                   # executes a subshell
more commands


2. even so we'd first have to do something like 

for i in `set` do
  export $i
done

And I'm not sure that would work properly, it's certainly ugly if you 
try it at the cmd prompt.


Elaine



More information about the Lunar-dev mailing list