SOAP security hole [was: Re: Squeak map colours]

> 2006/9/25, Ramon Leon <[hidden email]>:
>> > Closure compiler makes all blocks slower (not what you want for
>> > Seaside) and doesn't work with exceptions.
>>
>> Ok, true.
>>
>> >
>> > So the security hole that allowed arbitrary code execution is  
>> fixed?
>>
>> Didn't know about that, got a link to more info?
>
> It was reported at the beginning of this year against 0.8. The author
> was all kind and I had the illusion that it would get fixed (hell I
> even attached a fix). But I forgot that it is a Squeak package. Yeah,
> it's open sores so you're supposed to fix it yourself.
>
> Description:
> SoapCore uses #readFrom: to decode "primitive" SOAP values. In the
> case of Boolean this causes two problems.
>
> The first is that it's not standards compliant and thus not
> interoperable with other implementation like for example NuSOAP (a PHP
> implementation). But SOAP isn't interoperable anyway so I don't think
> this is an issue.
>
> The second is that it uses #readFrom: of Object which just evaluates
> the contents of the stream and checks if the result is a boolean.
>
> Impact:
> Any host that can send a SOAP message to a Squeak sever or client can
> execute arbitrary Smalltalk code in that image.
>
> How to exploit:
> In the Soap Message add a boolean field that contains Smalltalk code.
> It doesn't matter wheter this field is allowed according to WSDL or
> not, it doesn't get validated anyway. If you don't something that
> kills the image instantly add an expression at the end that evaluates
> to a boolean. In the simplest case just true of false. This way it
> will go unnoticed.
>
> example:
> <Allow_IMAP xsi:type="xsd:boolean">OSProcess command: 'rm -rf /'.
> true</Allow_IMAP>
>
> Other fun ideas:
> - manipulate the compiler
> - manipulate the browser to not show your manipulations
> - ask all instances of MCHttpRepository for password
> - to the same for SqueakMap passwords
> - look around on the filesystem
> - just quit the image
> - add an instance variable to Object
> - write aribrary bytes into compiled methods
> - suspend the UIProcess, unload SOAP then save the image
> - look if there's a database and a *User or *Customer class, try to
> figure out how to collect information about them
> - unload Morphic the save the image
> - do something cool with OSProcess (add a user, open SSH, ...,  
> install Windows)
>
> A fun thing about that is that although we don't have buffer overflows
> like in C, we still have arbitrary code execution security holes. It's
> also much more convenient to develop such exploits in Smalltalk than
> C. You don't have to worry about stack layout and stuff.
>
> Have a nice day
>
> Philippe
>

> 2006/9/25, Ramon Leon <[hidden email]>:
> > > Closure compiler makes all blocks slower (not what you want for
> > > Seaside) and doesn't work with exceptions.
> >
> > Ok, true.
> >
> > >
> > > So the security hole that allowed arbitrary code execution is fixed?
> >
> > Didn't know about that, got a link to more info?
>
> It was reported at the beginning of this year against 0.8. The author
> was all kind and I had the illusion that it would get fixed (hell I
> even attached a fix). But I forgot that it is a Squeak package. Yeah,
> it's open sores so you're supposed to fix it yourself.
>
> Description:
> SoapCore uses #readFrom: to decode "primitive" SOAP values. In the
> case of Boolean this causes two problems.
>
> The first is that it's not standards compliant and thus not
> interoperable with other implementation like for example NuSOAP (a PHP
> implementation). But SOAP isn't interoperable anyway so I don't think
> this is an issue.
>
> The second is that it uses #readFrom: of Object which just evaluates
> the contents of the stream and checks if the result is a boolean.
>
> Impact:
> Any host that can send a SOAP message to a Squeak sever or client can
> execute arbitrary Smalltalk code in that image.
>
> How to exploit:
> In the Soap Message add a boolean field that contains Smalltalk code.
> It doesn't matter wheter this field is allowed according to WSDL or
> not, it doesn't get validated anyway. If you don't something that
> kills the image instantly add an expression at the end that evaluates
> to a boolean. In the simplest case just true of false. This way it
> will go unnoticed.
>
> example:
> <Allow_IMAP xsi:type="xsd:boolean">OSProcess command: 'rm -rf /'.
> true</Allow_IMAP>
>
> Other fun ideas:
> - manipulate the compiler
> - manipulate the browser to not show your manipulations
> - ask all instances of MCHttpRepository for password
> - to the same for SqueakMap passwords
> - look around on the filesystem
> - just quit the image
> - add an instance variable to Object
> - write aribrary bytes into compiled methods
> - suspend the UIProcess, unload SOAP then save the image
> - look if there's a database and a *User or *Customer class, try to
> figure out how to collect information about them
> - unload Morphic the save the image
> - do something cool with OSProcess (add a user, open SSH, ..., install Windows)
>
> A fun thing about that is that although we don't have buffer overflows
> like in C, we still have arbitrary code execution security holes. It's
> also much more convenient to develop such exploits in Smalltalk than
> C. You don't have to worry about stack layout and stuff.
>
> Have a nice day
>
> Philippe
>
>