Slash Boxes
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.
More | Login | Reply
Loading... please wait.
  • SOAP::Lite (Score:2, Interesting)

    Everyone makes mistakes, but I'm astonished at Kulchenko (the SOAP::Lite author) for letting this one happen. It's appalling!

    NOTE TO SELF: When a user (especially an untrusted one!) gives you data that you expect to be in a particular format, CHECK THAT IT IS IN THAT FORMAT, FOR CHRISSAKES!

    This whole thing would have been avoided if anyone had had, earlier on, the wits to do what Ilya M did, basically die "BAD JUJU" unless m/\A[a-zA-Z][a-zA-Z_0-9]*\z/

    I say that unless Kulchenko shows up and immediately releases a fix version (MONTHS after this was mentioned in Phrack), he doesn't get to own that module in CPAN anymore, and ownership gets transferred immediately to someone else, so it can be patched RIGHT NOW! Letting this error get in was incompetence but letting it persist is deliberate negligence.

    • Re:SOAP::Lite (Score:4, Insightful)

      by jesse (2531) on 2002.04.09 23:55 (#6808) Journal
      Of course that leads into the discussion about how CPAN is a relative anarchy. SOAP::Lite is a namespace that pavel has registered and "owns". I've never seen anything that says there's a requirement that you have to maintain your code well to get a namespace registraion and upload it to CPAN. Personally, I'd love to see a tiered structure, as has been previously proposes, with "standard" modules that are maintained and managed as a standard library, "optional" modules with a refereed namespace and some level of QA and then the third tier free for all, which we all know and love. But yeah, we need a more general way for dealing with major security holes in popular modules.
    • This mistake is common in other XML-RPC libraries I've seen. It's hard enough to make the durn things work in the first place, let alone get the security right. This bug can be fixed, although SOAP::Lite allows *a lot* of leeway in its dispatch method.

      Some work is being done on the Frontier::RPC module(s). We'll have to look into this further.

    • Re:SOAP::Lite (Score:4, Informative)

      by paulclinger (1709) on 2002.04.10 20:29 (#6850)
      > but I'm astonished at Kulchenko (the SOAP::Lite author) for letting this one happen.
      I'm with you. I'm also astonished to find that it happened.

      It's expected to be in that format. The reason for the problem is that method name wasn't verified against list of allowed methods when *class name is on the list of allowed classes*.

      > MONTHS after this was mentioned in Phrack
      Do you read Phrack daily? I don't read it at all. Randall brought it to my attention some time ago, and I was surprised to find later that it was discussed on perlmonks and nobody told me about that discussion. Unfortunaty with my schedule I'm only an occasional reader of use.perl, perlmonks and other perl sites.

      > and ownership gets transferred immediately to someone else
      Even though there is no such procedure, I wouldn't mind to know more about the person who would like to take this ownership.

      I'm not trying to downplay the issue. It's my fault. In addition to that, it's probably the worse time for releasing a new version: I'm moving and have all my computers packed and shipped. I do have copies and repository with me, however I don't have my testing environment and only sporadic online access in my hotel. Still I plan to release bugfix by the next week. If you don't think it's reasonable, let me know.

      Best wishes, Paul.