[development] Think there's a security problem in your module? Here's what to do.

DragonWize dragonwize at gmail.com
Wed Jan 16 19:34:26 UTC 2008

My point is that it is not obscurity. It is the norm. I am not saying
to obscure anything I am say to do what you normally do. If you commit
an NON security commit it is no different than if you did. Changing
that just makes their job easier.

If they know what they are looking for, they will look for it. NOT
wait for it. If you know what you are looking for the easiest way to
find holes is by downloading the code anonymously and greping it. That
would yield a million times better results in seconds rather than
waiting days, weeks, or years for something to come through the cvs

And to find holes that are being created the only way a black hat
hacker would do it is to write a script that greps his working copy on
update everyday. Because looking through thousands of lines of code
everyday is not an effective means to their end. If it is, that means
they are very determined and there is nothing you can do to stop them
because they know the hole long before this security process ever
started and are already exploiting it.

On 1/16/08, Earl Miles <merlin at logrus.com> wrote:
> DragonWize wrote:
> > 2. making commit doesn't advertise anything unless you put a
> >  description saying what the security flaw is and how to exploit it.
> >  hopefully it is obvious to not ever do that, no matter when you commit
> >  it.
> >
> > Even after the SA has been released you should never commit a message
> > saying you fixed a security hole. That would be like putting the line
> > # of the hole in the SA. You don't say what the hole is, where it is,
> > or how to exploit it. This goes true for any commit you ever do.
> > Because then they have to find, which they had to find it anyway so
> > there is no difference between committing and not committing. In fact
> > if you coordinate the commit with the SA you are just making it that
> > much easier for them to find it.
> Security through obscurity does not work. It just makes it harder to
> tell when it doesn't work.
> If the author fixed a security bug, and black hat hackers are monitoring
> this, they *are* reading the code, and they *know* what they're looking
> for, and they are NOT going to share that data. It doesn't matter if the
> author annotated the fix in the CVS log or not.

Alan Doucette
Koi Technology, LLC

More information about the development mailing list