Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?

SOAP::Lite and Security (Phrack #58)

by Coyote (Deacon)
on Dec 30, 2001 at 01:34 UTC ( [id://135160] : perlmeditation . print w/replies, xml ) Need Help??

Developers using SOAP or XML-RPC will be interested in the latest issue of Phrack. RPC without Borders shows that it is fairly trivial to execute arbitrary functions (including Posix::System) using SOAP::Lite simply by using a full package specification when calling the function.

There is no spoon.

Replies are listed 'Best First'.
Re: SOAP::Lite and Security (Phrack #58)
by belg4mit (Prior) on Dec 30, 2001 at 03:24 UTC
    Ahhhh, the things Safe can save you from ;-).

    perl -pe "s/\b;([st])/'\1/mg"

      I'm not sure if Safe really helps. Suppose you have two subs in your code. Both use open to read some files and return data they have read. First sub should be directly accessiable via SOAP::Lite and second should not. How can Safe help here?

      Actuall fix is restrict package and method names that can be called via SOAP::Lite.

      Ilya Martynov (

        Well Safe restricts perlop's *and* namespace access so for that case you might put the second sub in a different package.

        perl -pe "s/\b;([st])/'\1/mg"

      JIK you read the article and are interested, I posted the use Safe; comment there as well (I did not plagarize ;-). However since they use a low resolution timestamp, and an UNobfuscated email address as an indentifier I did not give a valid address.

      perl -pe "s/\b;([st])/'\1/mg"

Re (tilly) 1: SOAP::Lite and Security (Phrack #58)
by tilly (Archbishop) on Jan 01, 2002 at 04:00 UTC
    The first thing I note is that their code examples involved symbolic references. Therefore the initial explanation of the gotcha involves a programming practice which strict would protect you from.

    However the mistake in the SOAP implementation is different. It is using the dynamic method lookup that Perl uses. This is not catchable with strict. This is an important detail. Someone trying to figure out why things work based on their coding example would be looking to the wrong dispatch mechanism and therefore they would seriously misunderstand what is going wrong.

    But the fundamental problem is that SOAP is a poorly designed protocol designed with no eye to security, and built largely for the convenience offered because most firewalls will let through http traffic. This was said pointed out a long time ago by Bruce Schneier, but it is amazing how many people have missed the basic point. The point is that firewalls are retroactive protection for security mistakes in applications. If applications seek new ways around firewalls but continue to make the same basic mistakes then you are guaranteed to get into a situation where firewalls need to retroactively filter a more complicated protocol. Wonderful.

    (What I actually want is for Microsoft to build into the OS something that requires SOAP tunnelled directly over https - so that the encryption in https makes it impossible to filter their inevitable security mitakes. When that happens I will have something concrete to stand on to argue for completely removing Microsoft from corporate networks. Remotely exploitable security holes which cannot be blocked and cannot be filtered. Lovely. But I digress...)<p Anyways back to the horrible security hole in Perl SOAP implementations. Well the security hole is obvious, and it is what I pointed out at Re (tilly) 1: Orthogonal Code and Security. The problem is that the SOAP server is using its ability to serve a request as synonymous with its permission to serve that request. Given that anyone can construct any request they desire, this is a huge problem. Given the number of people who seem inclined to follow the latest stupid buzzwords, this guarantees that many will follow the easy path towards a series of obvious mistakes which will give people like myself things to complain about for years to come.

    I am positive that SOAP implementations in other languages are going to be making the same mistakes that Perl's do. Just a guaranteed side-effect of having network protocols designed by people without a clue about security implemented by other people who likewise lack clues.

    If you want to use SOAP, do as is suggested in the article. Put your functions into a hash. Don't let any function not in that hash be called. And should you need to implement any security model more complex than, "This is publically accessible, that is not", then I wish you luck...