[Savannah-hackers] Re: [Savane-dev] Re: auditing the savannah code

[Mathieu Roy]

"Lorenzo Hernandez Garcia-Hierro" <address@hidden> tapota :

> Hi,
>> >
>> > Hi,
>> > Finally i get working my account in savannah.gnu.org .
>> > Other important thing:
>> > I am auditing the source code of savannah ( i got it by CVS and it is so
>> > much buggy
>>
>> Please get your copy at <http://gna.org/projects/savane> , this is where
>> the development continue. The CVS at Savannah is out of
>> sync. Especially if you are looking at the trunk.
>
> I know , differences are not so much , just some files are not in savane.

Well, the code of the task tracker, support tracker and patch manager
has been completely dropped. 

I would not say differences are not so much. No files remained
untouched during this period. 

The statement that the CERN branches constitutes the biggest changes
in the whole Savannah project history, after the addition of the bug
tracker written by Laurent Julliard, would be hard to challenge, I think.

Here comes the relevant commitinfo from the CVS merge that gives an
overview:
<http://cvs.gna.org/viewcvs/*checkout*/savane/savane/ChangeLog?rev=1.400>

Basically, if your study as been made on the CVS trunk at
savannah.gnu.org, it is likely to be completely outdated. :( 

However, we'd still be interested in an audit of the current code.


>> At the time the server was compromised, there were unknown heavy
>> security holes in CVS and rsync, and known bugs in the running kernel
>> (ptrace, do_brk), largelly enough to completely compromise the
>> server.
>
> ptrace is so old and remotely exploitable but functions like do_brk and
> m_remap
> ( this one part of VMA kernel code ) are exploitable in local environment.

I know. 

As I wrote, there were already two major holes in CVS and rsync that
allows to do whatever you want, since the kernel was exploitable via
ptrace and do_brk bug. So guessing how the compromised has been done
is a matter of choice...

The truth is simple: there was no real integrity check, no separation
between services, no frequent security check (Vincent Caron find the
rootkit almost by chance, and was member of the team since less than 3
months). It is sad to say, but it was meant to happen, unless someone
had the idea to make that changes (integrity check, services
separation, frequent security checks) ; but it was anyway at that time
not technically possible (running out of hard disk space, I had to
move data every two month over the hard disks -- no room left to think
about how to separate services).

>> And at that time, the running version of Savannah was the old
>> trunk, before the CERN developments, so there is not much in common
>> with the current code.
>
> I am not sure but i think the code is quiet similar

It is not. I think I'm probably the persons that knows best the code
(no surprise, I have been paid 2 month to work on it by the CERN, and
it gives time to get familiar with the code), and I can tell there is
not much in common. 


> . I will make a diff between newer code of savane and oldest.  At
> the moment i have tested the vulnerabilities i found.  Please ,
> remember: restructuring the code is not securing it. 

You are right. No doubt, the fact that the code have no more anything
in common does not means that there is no longer any security risk.

However, trashing a lot of duplicates functions make easier to track
down security risk, and the remaining code for the trackers come from
the bug tracker written by Laurent Julliard, younger and probably way
better than the original SourceForge trackers. 

>> > .  I am preparing an audit paper ( currently i have wrote a lot but
>> > it is not finished ).  I am sending this message to savannah hackers
>> > too.  If help is needed ( in savannah ) i can work out with it ,
>> > patching and recoding some parts.
>>
>> Please, send it first to address@hidden so we can take necessary
>> action to avoid any installation to be jeopardized, if there is a
>> risk.
>
> I will send it without finishing and if i discover more things i will send
> them too.

Thanks.

You can send a copy to address@hidden too.


>to take a look to what you already wrote, so
>> I would be grateful if you can send it to me as soon as possible.
>
> Ok.
>
>> > I think we must recode savannah in order to stop using global/super
>> > global variables.
>>
>> We are aware of the issue. There is a task open about that, but that's
>> an heavy work. However, we have tested potential problem with that,
>> and find nothing conclusive. Most PHP programs more than two years old
>> have this register globals issue.
>
> I can help with it.
> i  want to enter the project ,  jut review some of my works  and tell me if
> you are interested.

We are interested. 

As it requires heavy changes, it should be done on a specific
branch. You can create an account for yourself at https://gna.org,
send a gpg-signed mail mentioning your account name to
address@hidden, and I'll give your write access, and give you
pointer on the way to work with the CVS (how we want to handle
branches and stuff). 

We already discussed about that change recently at address@hidden,
the development list of Savane, and reached the conclusion that was
definitely the way to go. But as I said, it is a lot of work, because
in many cases variables can be set in multiple ways.

Regards,

-- 
Mathieu Roy

  +---------------------------------------------------------------------+
  | General Homepage:           http://yeupou.coleumes.org/             |
  | Computing Homepage:         http://alberich.coleumes.org/           |
  | Not a native english speaker:                                       |
  |     http://stock.coleumes.org/doc.php?i=/misc-files/flawed-english  |
  +---------------------------------------------------------------------+