devicemap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Werner Keil <werner.k...@gmail.com>
Subject Re: Separate "Console" from Java Client
Date Thu, 08 Jan 2015 15:17:36 GMT
Believe me these things happen and I'm not making something up to "scare
you" or back the argument, I am asked by customers not only for performance
or overall architecture analysis, but often also threat assessment of
various kinds. Reaching from relatively simple things like that to "are our
servers in a cluster far enough from each other to withstand total
destruction of one or more by Terror, Natural Disasters, etc.?"

Werner



On Thu, Jan 8, 2015 at 4:13 PM, Werner Keil <werner.keil@gmail.com> wrote:

> 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 <
> reza.naghibi@yahoo.com.invalid> 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 <werner.keil@gmail.com>
>>  To: dev@devicemap.apache.org
>>  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
>> <reza.naghibi@yahoo.com.invalid
>> > 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 <werner.keil@gmail.com>
>> >  To: dev@devicemap.apache.org
>> >  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
>> >
>> >
>> >
>> >
>>
>>
>>
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message