I know Robin has close ties with WebCentral. Is macromedia aware that Australia's largest hosting company does not support flash remoting.
Brian Knott -----Original Message----- From: Beattie, Barry Sent: Thursday, 11 December 2003 10:22 AM To: CFAussie Mailing List Subject: [cfaussie] Re: Flash Remoting exploits (was: Flash Remoting and - WebCentral) >> if it were a public DOS I'm surprised MM.com isn't hit by script kiddies every day. Geoff, this is the reason why I regurgitated Brian's post. Either webcentral is right (and we've then got problems) or they're not (and they need a bit more "education"). This is where your reply (and others) will help. Brian now has a decent argument to take back to them and correct their service provision agreement. and if they won't then others who don't fear the technology (thanx for the links, Gary) will have a competitive advantage. anyone else want to chime in? cheers barry.b -----Original Message----- From: Geoff Bowers [mailto:[EMAIL PROTECTED] Sent: Thursday, 11 December 2003 9:48 AM To: CFAussie Mailing List Subject: [cfaussie] Re: Flash Remoting exploits (was: Flash Remoting and - WebCentral) I'm no remoting security expert but doesn't the flash sandbox prevent this from happening? In other words you can only remote from a flash file that has been delivered from the same domain. You can't just remote to any old server from your flash movie -- well that is my understanding. Seems like a DOS that can only be run by developers with access to the server -- if it were a public DOS I'm surprised MM.com isn't hit by script kiddies every day. If it is a DOS that is only applicable in a shared environment I would have thought it would be simplicity itself to track down the perpetrator and ban them from the service. But like I said.. I'm no expert. -- geoff http://www.daemon.com.au/ Knott, Brian wrote: > My understanding of the situation is that Flash Remoting is just using Web > Services. Does the same problem exist for web services. > > Brian Knott > > -----Original Message----- > From: Beattie, Barry > Sent: Thursday, 11 December 2003 8:48 AM > To: CFAussie Mailing List > Subject: [cfaussie] Flash Remoting exploits (was: Flash Remoting and > WebCentral) > > > 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 --- 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 --- 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
