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

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 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."

    • 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:

      What are the impacts of the fixed vulnerabilities?

      It’s not always clear what a particular hole can only be abused for, and in particular, whether or not it allows priviledge escalation. Of particular interest in webapps is whether there is a chance of priviledge escalation between environments, eg. whether a bug only allows you to delete documents in a CMS that you shouldn’t have access to, or whether it actually allows the attacker to puncture the app abstraction and gain direct access to the database or the filesystem on the machine.

      How can they be exploited and is any authentication required?

      Eg. in this case, would the GET-vs-POST attack required that the user be cookied or otherwise have priviledges? Again – can this result in priviledge escalation?

      Which other versions are also affected and are there any mitigating factors?

      In other words: a) How do I tell whether I run a vulnerable version? b) As a user of a vulnerable version, is there anything I can do to close the hole without patching any software? (Eg. in browser hole advisories this is where the inevitable “to avoid exploitation, disable Javascript support” comes in.)

      It should be obvious that these aren’t questions a casual observer can judge merely by looking at a patch if an exploit has not been published.

      It should also be obvious that giving answers doesn’t mean providing a HOWTO Exploit MySoftware v0.42.