Hmm,

Isn't that the same as saying anyone who writes a CFC can do the same thing as Flash Remoting? To my understanding of Flash Remoting, isn't CFMX still the engine that invokes Objects, and all Flash Remoting does is execute the method contained within a CFC? (ie is it Flash remotings fault or is it cfmx fault).

So in saying this, if you where to use CreateObject() to execute that java.util.ArrayList it too would be a denial of service attack?

I know you can use flash clients to connect to other peoples domains, (especially if you use local executables - much like the same way you would via webservices / soap).

Scott
http://www.mossyblog.com


Beattie, Barry wrote:


wow!

if WebCentral doesn't want to touch remoting then I suppose no one will -
unless they're wrong or an easy/workable fix exists.

these are the bits that get me:

<!------->
... connect to java.util.ArrayList as a Remoting service through Flash
Remoting and invoke ArrayList.addAll(new Array("some string")) in an
infinite loop. This is basically a denial of service attack ...
<!------->

and

<!------->
... Macromedia's recommended approach for dealing with this security issue
is to
enable the Java Security Manager ... Unfortunately, the Java Security
Manager will slow down your application server ... and you can't prevent the
ArrayList exploit above because the Remoting gateway needs access to
ArrayList to function. The Security Manager can not distinguish between the
gateway using a class as a Remoting service or as part of its written code
...
<!------->


Anyone form Macromedia got a comment on this?


any comments at all?

worried
barry.b


-----Original Message-----
From: Knott, Brian Sent: Wednesday, 10 December 2003 2:40 PM
To: CFAussie Mailing List
Subject: [cfaussie] Flash Remoting and WebCentral



Does any one know an ISP that supports Flash Remoting. Web Central does not, they don't tell you that until your app does not work and you ask them why. Below is an extract from an email they sent me.

Anyone form Macromedia got a comment on this.

Brian

Macromedia Flash Remoting is implemented as a servlet that uses
introspection to invoke methods on a class in the application server. The
class and method are both named by the Flash client. A Flash MX client can
invoke any method through the Flash Remoting gateway on any class that has a
no argument constructor and can therefore be created by the Flash Remoting
gateway servlet using Class.forName("package.ClassName").newInstance( ). It
can also invoke any method on any EJB home interface that it can find in
JNDI.
This opens up many potential security issues. A malicious user could write a
Flash client to access known core Java classes, classes in the application
server APIs, or classes in your application. The potential exploits are
numerous. A Flash client could access application server classes to
manipulate the state of the server or gain access to protected information.
Using the core Java APIs a Flash client can connect to java.util.ArrayList
as a Remoting service through Flash Remoting and invoke ArrayList.addAll(new
Array("some string")) in an infinite loop. This is basically a denial of
service attack that will fill up the memory available to the application
server. Before long, it will crash the JVM (Java Virtual Machine) running
the application server.
Macromedia's recommended approach for dealing with this security issue is to
enable the Java Security Manager for your application server and edit the
Java security policy file to limit the classes the Remoting gateway servlet
can access. Unfortunately, the Java Security Manager will slow down your
application server, security policy files are difficult to edit and manage,
and you can't prevent the ArrayList exploit above because the Remoting
gateway needs access to ArrayList to function. The Security Manager can not
distinguish between the gateway using a class as a Remoting service or as
part of its written code.



--- You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED]

MXDU2004 + Macromedia DevCon AsiaPac + Sydney, Australia
http://www.mxdu.com/ + 24-25 February, 2004



-- Scott Barnes http://macrofun.pvpers.com


--- You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED]

MXDU2004 + Macromedia DevCon AsiaPac + Sydney, Australia
http://www.mxdu.com/ + 24-25 February, 2004

Reply via email to