Re: Windows/Macro Language Info?


In article <3bf3l3F6fsqaaU1@xxxxxxxxxxxxxx>, "Pete Dashwood" <dashwood@xxxxxxxxxxxxxx> writes:
> "Richard" <riplin@xxxxxxxxxxxx> wrote in message
> news:1112670347.953014.47280@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> > > No, Java scriptlets and servlets can also carry malware.
> >
> > Servlets run the server (hence the name) and cannot 'carry' anything to
> > your machine.
> >
> You are showing limited imagination here, Richard. Servlets DO run on the
> server but they can formulate HTML and transmit it to your system, and they
> can activate programs on other servers to attack ports on the client,
> especially once they have its IP adress and therefore know it is active.

There's absolutely nothing here that distinguishes servlets from any
other part of the HTTP server. Any HTTP request can cause arbitrary
actions by the server (or servers) that receives it. The HTTP server
could "formulate HTML", "activate programs on other servers", and so
forth. Claiming that this is in some way a property of servlets is
inconsequential; it's a property of everything that runs on the server
side. PHP can deliver malware and coordinate attacks to precisely the
same extent that any server (including "nc -L") can.

> > By 'Java "scriplets"' I presiume that you mean applets, which do run on
> > the client machine.
> >
> No, having written both servlets and applets I not only know the difference,
> I understand the implications.

So what is a "scriptlet", then? JSPs? They're just syntactic sugar
for servlets. No security difference whatsoever.

> > > I totally understand the difference between client and server side
> >
> > "servlets carrying malware" ??
> >
> If they are running on a 'malicious server', certainly...

How? The servlet is not downloaded by the client. It can serve
malware, but so can any other component of the server - a servlet
serving malware is no different from a static link to malware.

And the malware is only effective if the client has an exploitable
vulnerability; and the more capabilities the client has, the more
potential vulnerabilities there are. That's why client-side
scripting languages are an additional exposure on the client, and
server-side scripting languages are not.

They're an exposure on the server, which may lead to a compromised
server serving malware, but the server-side scripting facility itself
is no more of a malware vector than serving static content is.

> > Certainly JavaScript can be used as server side, or even as a command
> > line language. But it will only act as a malware carrier when it is
> > running on the client.
>
> Again, I say your imagination is limited...

Malware, or anything else, is delivered to the client as a stream of
octets. It doesn't matter what generates that stream of octets. It
could be a server-side script; it could be a static file; it could be
hard-coded into the server program itself. From the client's point
of view it makes no difference whatsoever.

> I have placed programs onto a server using certain ports and certain
> protocols (not http) that the user was completely unaware of ... (it was my
> machine and I did it while experimenting with Java Network protocols...
> There was no visible sign the transfer had occurred, but it had. All it
> needed was a signal to activate it. That is why we (should) have firewalls.

Certainly, but what does that have to do with server-side scripting?

> It is also the main reason most sysops disable Telnet until they actually
> require it. The protocol I used was not Telnet and I'm really loth to
> discuss this too much because it may give some people ideas.

No worries there. The script kiddies aren't bright enough to use
them, and the real black hats are way ahead of this sort of thing.
They're using side channels in DNS and the like as transports.

Most people disable telnet because they can get a somewhat more
secure remote login mechanism from SSH with little effort. (As it's
typically used, SSH is still vulnerable to numerous plausible
attacks, because people don't usually practice good key hygiene, but
it provides "kid sister" security, anyway.) Of course, there are a
variety of secure telnet implementations available, some of them
significantly superior to SSH as it's conventionally used.

Telnet's hardly the major target anyway. Far more exploits against
Windows systems are tunnelled through DCOM, SMB, and HTTP, which have
traditionally been the gaping holes in Windows network security.

> > A Java applet in a page from a server is running in a sandbox and has
> > no access to local resources. It can't write local files or access the
> > local machine. It can only link back to the originating server.
> >
> That is what is stated in all the Java texts.
>
> I also believed that to be the case until recently. It can be bent.

There have been a number of exploitable holes found in Java
sandboxing, some in the core language implementation and some in
particular JVMs.

There have been far, far more exploitable holes found in ActiveX
controls. In particular, a great number of ActiveX controls marked
"safe for scripting" have, in fact, been proven to be completely
unsafe.

Historically, user agents (such as browsers) which permit ActiveX
executable content have been far more vulnerable than those that
permit only Java executable content.

> I think this is the most sensible and non-emotional discussion and it
> accurately reflects my own position.
>
> http://www.cs.princeton.edu/sip/faq/java-faq.php3

Sure. Ed Felten's a good guy (he took on SDMI, after all, which
practically makes him eligible for sainthood in some people's eyes)
and a good security researcher. And his baseline assessment is
correct: neither ActiveX nor Java should be considered secure.

However, making security decisions from baseline assessments -
especially decisions along the lines of "oh well, we're all in
trouble anyway, so what difference does it make?" - is lousy security
practice. Good security decisions, the sort that make a difference
in actual security costs and damages, are made based on realistic
threat models and analysis of how various countermeasures mitigate
various threats in it.

And the fact is that the available evidence suggests strongly that
restricting ActiveX prunes a larger portion of the attack tree than
restricting Java does.

Now, I'm not aware of any evidence that demonstrates a similar
disparity between VBScript and Javascript, and I'd be surprised to
see any, since I'm not aware of any significant capability the former
has and the latter lacks, when executed by an HTTP user agent. I
make it my practice to never execute scripts served by web pages
without confirmation, except for a few internal systems that I trust
(on the grounds that if they're compromised I have much more grievous
exposures to worry about anyway).

> SSI can do quit a bit more than Server Side Includes, as
> its name implies. It can execute programs in some implemenations of it.

But this makes *no difference* to security from the client's point of
view. Anything done *to the client* by a program executed by SSI or
CGI or any other server-side facility could be equivalently done by
the base server software itself. The client can't tell the difference.

Server-side scripting has historically been a vulnerability for the
server. In the early days (say, the NCSA httpd 3.0 era) it was
unsafe sample CGI scripts; then for a while poorly-written Perl
scripts and Visual Basic COM objects with lousy input hygiene; and
these days I see lots of exploits against sloppily-written PHP apps.
And these vulnerabilities lead to server compromises, and a user who
trusts a compromised server may well be compromised in turn. But
that doesn't make server-side scripting a client-side vulnerability.

--
Michael Wojcik michael.wojcik@xxxxxxxxxxxxxx

Thanks for your prompt reply and thanks for your invitatin to your
paradise. Based on Buddihism transmigration, I realize you, European,
might be a philanthropist in previous life! -- supplied by Stacy Vickers
.

Relevant Pages

  • Re: Windows/Macro Language Info?
    ... >> can activate programs on other servers to attack ports on the client, ... > There's absolutely nothing here that distinguishes servlets from any ... > other part of the HTTP server. ... I guess I got pushed into it when it was suggested that SOME scripting ...
    (comp.lang.cobol)
  • Re: J2ME or network programming or...what do you recommend?
    ... recommend more of specialization (knowing less technologies, ... I started doing the servlets along with the JSP. ... Well depending on how dynamic you want the client to be. ... needed) to java server programs? ...
    (comp.lang.java.programmer)
  • Re: [Full-disclosure] windows future
    ... The reason to believe the exponential model will remain valid, ... Did you see the link I posted to the "Evolvable Malware" PPT? ... I have already decommissioned one server, ...
    (Full-Disclosure)
  • Re: asrock, problem with nic after windows-boot - Exact Opposite issue the OP is having
    ... the "power switch" on the front panel, and the O/S would cleanly terminate ... before turning off the power. ... For shell scripting, start with the Bash-Prog-Intro-HOWTO ... X really doesn't belong on a server, ...
    (comp.os.linux.networking)
  • Re: Banana Republic (was Re: OpenVMS Book Wins award)
    ... page but didn't look deeeply enough to see that the client was having to ... (for the same host). ... cross-site scripting constraint exercised by the browser (to prevent XSS ... but what is outside any HTTP protocol is "when a server gets told something" ...
    (comp.os.vms)