If someone gets shell access to a server and decides to run DeviceMap
benchmarks, what would be kind of funny :)
Regardless, again, im in total agreement. org.apache.devicemap.cmd.Main belongs
somewhere else. Its not core functionality.
From: Werner Keil <[email protected]>
To: [email protected]; Reza Naghibi <[email protected]>
Sent: Thursday, January 8, 2015 10:13 AM
Subject: Re: Separate "Console" from Java Client
If someone gained shell access to a server they don't need to use the Web
interface (which normally should respond to foul-play or DOS attempts by
refusing connections anyway) They also don't even need root or sudo rights
here. As Open Source files can be found publicly available so knowing the
source a simple batch/shell against the JAR would work without writing Java
code yourself.At the moment DeviceMap may not be as widely deployed as Apache
poster children like Tomcat, etc. but it's visible and the command line
environment does not have the same security managers protecting the Web
container, so the JAR somewhere in most file systems (a "webapp" folder, "tmp"
or similar) could be used to script an attack. Where the extra power (and some
risk) of console access is desired by a company they can add it, but it should
be their choice, not pre-bundled under the hood.
On Thu, Jan 8, 2015 at 3:48 PM, Reza Naghibi <[email protected]>
wrote:
You can only DOS code which is exposed on the web. I dont think calling a
main() method is a common practice in web development. If a developer chooses
to do this, more power to them. Its a choice, not a risk.
From: Werner Keil <[email protected]>
To: [email protected]
Sent: Thursday, January 8, 2015 9:29 AM
Subject: Re: Separate "Console" from Java Client
It offers just "read only" access, so data could not be destroyed directly,
but a DOS (Denial Of Service) attack by executing Ten Thousands or Millions
of UA strings would already be risk enough to most companies. This happens
in similar ways e.g. against SQL databases and unless it's a really
unprotected enterprise server, those are also done much easier against a
console interface like Oracle SQL*Plus.
Werner
On Thu, Jan 8, 2015 at 2:35 PM, Reza Naghibi <[email protected]
> wrote:
> While I totally agree with you that org.apache.devicemap.cmd.Main can and
> should live somewhere else, it is in no way, shape, or form a security
> risk. There is no 'shell' in there.
>
> From: Werner Keil <[email protected]>
> To: [email protected]
> Sent: Thursday, January 8, 2015 8:27 AM
> Subject: Separate "Console" from Java Client
>
> Hi,
>
> As discussed mainly here in JIRA
> https://issues.apache.org/jira/browse/DMAP-54 it seems advisable to
> separate the "Console" (Main class) from the actual Java Client.
>
> An optional W3C module on top of it already suggests bit of modularization,
> so a small optional module (pretty much similar to the "Console Example"
> which is the actual subject of DMAP-54) would further improve this.
>
> Most importantly baking a console shell into the client library poses a
> security risk because it requires little more than a batch or shell script
> to run UA queries against that and it runs in a Java SE context. All known
> Java vulnerabilities of the last months and years affect Java SE in a
> standalone/desktop environment, a proper EE container is usually well
> protected as well as code running inside it. While a JAR that exposes
> console functionality may be abused via scripts much more easily.
>
> Regards,
>
> Werner
>
>
>
>
