Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Beatnik (493)

Beatnik
  (email not shown publicly)
http://www.ldl48.org/
A 29 year old belgian who likes Mountain Dew, Girl Scout Cookies, Tim Hortons French Vanilla Flavoured Cappucinno, Belgian beer, Belgian chocolate, Belgian women, Magners Cider, chocolate chipped cookies and Perl. Likes snowboarding, snorkling, sailing and silence. Bach can really cheer him up! He still misses his dog.

Project Daddy of Spine [sf.net], a mod_perl based CMS.

In his superhero time (8.30 AM to 5.30 PM), he works on world peace.

Journal of Beatnik (493)

Wednesday January 03, 2007
08:38 AM

Secunia security vulnerability reports

[ #32058 ]
Today, I received a short mail from Secunia asking me for details of the fixes I did to Spine. I'm not sure what to answer.. It doesn't appear to be automated. How far would any vendor go by providing security companies with ways to exploit their own software? Wouldn't it be wise just to say "No comment" and let them sort it out for themselves? I'm not even sure I have the time to respond and work out some examples since I'm out of the country next week..

Hello,

we noticed the following entries in the changelog for SPINE 1.2 stable
and are about to release an advisory for these issues.

* Added in Admin : Forced POST access (prevent XSS)
* Fixed in Core : Placeholders in database handler : security fix
* Fixed in Admin : Macro admin security bug fix

Before we publish our advisory we would appreciate to receive your
comments on these issues.

What are the impacts of the fixed vulnerabilities?
How can they be exploited and is any authentication required?
Which other versions are also affected and are there any mitigating
factors?

Please respond as soon as possible.

Thanks in advance and kind regards,


List all Journal entries
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Secunia security vulnerability reports 6 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.

  • That's interesting. The "macro admin security fix" is something I don't understand, but the first two should be no brainers. Why the heck can't they figure that out for themselves? I do understand your reluctance to get specific about "here's how you attack unpatched versions of this software."

    • Actually, the items on that list are just copied from my Changelog. The first fix is basically to prevent people from creating a link like http://site.com/admin/delete?name=page.. but then again, they can still do a form with POST and have a javascript link to submit it.. *ARGH*

      The second one is just applying some best practices. Adding an extra lock to the already locked door.

      Third one is uhm.. mmm will have to look up what I meant by that tho :)

      Recommended action would be to upgrade.. obviously but not

    • I don’t see what’s so unusual about the request. Figuring out the issues requires study of the source code, and evaluating them to figure out what follows from them is often unclear to someone without a good understanding of the codebase. This has been a point of tension between the Linux kernelhackers and distributors, who often can’t tell how significant a bugfix really is without either being told or investing significant effort of their own.

      Let’s take a look at the questions:

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.