On Wednesday, August 9, Justin Wells wrote:
>
> Wrong. I run a public CVS archive. People are always examining the diffs
> and would notice right away. Same is true for any free/open software project,
> you just don't get it, that's all.
It is still entirely possible to do. I've seen this done, and
it is not all that hard. Yes, the more people that have this
particular module checked out, the more eyes that may catch this
sort of thing, but it is not impossible.
> > Any sufficiently powerful language is effectivley Turing Complete --
> > i.e. will allow the cracker to do dangerous things.
>
> This sounds clever, but everything it says is wrong: there are turning
> complete languages that are not dangerous, and there are languages which
> are sufficiently powerful (for some purpose) but not turning complete.
>
> You're just trying to sound clever, but it's not working.
It's Turing, not turning. For all intense and purposes, we are talking
about some data (whatever it may be, language, etc) being read and or
manipulated by a C program. Should there be a fault in this C program,
or any of the library functions within the call path, then this particular
program is exploitable. It does not matter if the language being implemented
is Turing complete or not. Even Java (TM) had buffer overflows within
some of its implementations. I'm sure that there are still some lurking
there somewhere...
I believe that there is a fundamentally different issue that needs to be
taken into account here.
Why would you create "yet another method of accessing a service/machine"?
Think about it for a while. There are a number of ways of accessing a
machine and any service it provides. In particular if you wish to also log
and otherwise track what these processes and users do on this machine. Why
create another, orthogonal method, another door for hackers to knock on and
try to circumvent? Since CVS uses *SYSTEM-LEVEL OBJECTS* as first order
objects within its organization of the data it keeps on the server, it will
invariably run into having to use at least some system level access controls
in order for it to access/create/modify/delete these objects. Also, since
people in general wish to have access control on a user basis, this also
necessitates that the server to authentication, in order to identify itself
to the system in the "appropriate" way. Why should CVS need to create yet
another namespace in order for people to authenticate themselves against
(the CVSROOT/password, or whatever file), only for the server (CVS) to then
setuid() itself (authenticate/identify itself to the system) to the
"appropriate" user, such that the system-level access controls on the
repository file actually work as the system intended to begin with? In my
books it makes no sense.
In other words, why was pserver invented? Because *CVS clients did not
wish to implement the rsh protocol? Or because the rsh protocol was usually
blocked by various firewalls? Wow, so we (or someone) implemented one of
the worst protocols *ever* in existance instead? (Authorization and
integrity wise...) Now somebody wishes to "fix" this by doing a nserver
implementation? Unless this implementation includes some form of *real*
authentication and integrity of the connection, I fail to see how it will
be "better" than crappy old pserver... It will be redundant.
There are other ways already in existance. SSL comes to mind, as does
SSH, as does SRP. I'm sure with a 5 minute search I could come up with
a list of 1/2 dozen suitable candidates. Why were these not implemented
on the client side? I figure it has something to do with the path of
least resistance. IE: the easy road will be the road most often traveled.
So, instead of "upping" security on the net, by blocking rsh access to
services, and using ssh (or other suitable replacement), we give the
script-kiddie community (no half-way respectable hacker would consider
hacking CVS pserver even worth the challenge) yet another way to make
them feel good about themselves. Hell, as a "noble" cause, were going to
make it "harder" now by using a chroot() call in the appropriate place.
I can already hear the "triumphant boasting" of script-kiddies that will
find some way to break the chroot() method of securing a CVS server.
I'm a hardliner, and am going to say "down with inferior protocols". May
they die a quick, and painless (for most of the unix world at least) death
they should have died 10 years ago. To the rest of the people out there
promoting and encouraging the continued use of such protocols, shame on
you.
I'd love to get one question answered by the *CVS (WinCVS, etc) folks.
Why is SSH (or SRP, etc) support not built into the core functionality
of your systems, should your platform/system not give native support?
--Toby.
