[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Savannah-hackers] Re: auditing the savannah code
From: |
Lorenzo Hernandez Garcia-Hierro |
Subject: |
[Savannah-hackers] Re: auditing the savannah code |
Date: |
Sun, 28 Mar 2004 15:56:15 +0200 |
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.
> There are bugs open at <http://gna.org/bugs/?group=savane> but none is
> blocker.
>
>
> > ) and i discovered a big couple of vulnerabilities result of
> > incorrect variable handling that can conduct for example in remote
> > command execution ( using virtual shell provided by php commands and
> > using the web server user rights )
>
> I'd be very interested to get information about that. Several persons
> reviewed the code previously and nothing really problematic was ever
> found. Especially after the Savannah compromised, some persons publicly
> questioned security of the Savannah code, without mentioning one line
> that could explain the compromise.
Most "whitehats" don't appear publicly and only the the "boys on the ship"
appear saying this is secure ,
this not , etc .
Reviewing the code of Savannah requires experience detecting problematic
codes and
a good security skill.
Good whitehats think as the intruder , others simply think as themselves.
> 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.
this can be conducted by using a virtual shell , as provided by webserver
scripts.
> 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 . 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.
Main functions i have seen in html.php , vars.php , etc under /include are
common between savane and the "old" code.
> I remember having found some insecure stuff
> while working at CERN on Savannah, but nothing that could lead to
> remote exploit, in the worse case, it was just about inserting in the
> database erroneous information, not impacting the system in anyway.
I have ( not finished ) a complete paper about the things i found.
I am including file names and lines with buggy code.
> > . 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.
> Please do not send it to a public list like savannah-hackers until we
> checked how it can affect the existing installation.
Ok , normally i respect this behavior except if the affected community don't
cares.
You are caring of , thanks !
> In the meantime, I'd like 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.
> 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 |
> +---------------------------------------------------------------------+
>