Boost logo

Boost :

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-07-31 09:31:03


--- In boost_at_[hidden], David Allan Finch <sarum_at_v...> wrote:
> Valentin Bonnard wrote:
> > I have never seen one. But Java is just another programming
> > language, and one can write viruses in just any language.
>
> As Java was designed specifically not to allow virus
> on your machine unlike some other portable languages
> I would dispute this. As there are no known Java
> virus you could say this is proof but negative proof
> is not proof.

But there are known Java viruses. A very quick web search turned up
two: Strange Brew (admittedly a non-issue for applets) and BeanHive
(which shows a true virus written in Java running as an applet). The
sandbox makes things much more difficult, but not impossible. The
reality is that nothing could make it impossible. There will always
be some way around any security barrier invented by man.

> > > I think you are mistaking this with a Visual Basic virus.
> > No, I know what Java is and what VB is.
>
> To my knowledge all current email virus are in VB
> which has no security or sandbox, M$ only added the
> signature protection afterwards and noone as far as
> I can see uses it. This is sharply different from java
> which had it from day one, infact M$ ridiculed
> Java security features saying they where not needed
> and put forward VB as good enough for the job.
> One could say Sun where right and M$ where not
> considering the many VB viruses that infect the
> M$ OS world.

MS bashing aside (shows poor profesionalism, IMHO), you are correct
that VBScript is much more dangerous than Java applets. Even MS
knows this... as evidenced by the upcoming ILM.
 
> > In theory. I have seen a Java program that had a tendancy to
> > dump core.
>
> As do all programs. Dumping core is not the same
> as having write access you your OS unless you are
> in a monitor where you can possibly write outside
> your address space, something even running in
> an embedded system you should not beable to do in Java.

An application specifically designed to dump core is an insidous and
dangerous program. Java does not prevent such attacks. It also
doesn't prevent starvation attacks.
 
> > There are some Java-related exploit and I don't
> > see why that would stop. There was also the mis-feature
> > that once you have downloaded a Java bytecode and saved
> > it on your disk, it can anything it wants (because it is then
> > a local file).
>
> A virus is self infecting, what you have just described
> is called a Trojan. IE you down load a game and it is
> infected with a Trojan. These are different kettle of
> fish from virus. I will agree that a Java program could
> be a Trojan but this is not the same as saying a Java
> program can be a virus.

Virus, Trojan, Worm. All are technically different beasts, but they
represent the same problem and dangers and are typically lumped
together in the same category. I don't care if it's a virus or a
trojan that trashes (or crashes) my system.

> Please do not get me wrong here, I do not think Java
> is wonderful. It has many problems, I am only objecting
> to your assertion that Java can be a virus. As it was
> is a specific design goal for Java that it could not be
> used this way, and it has yet to be proved it can, I
> feel relative safe in say it will not shown to be possible
> either.

There have been numerous Java exploits in the past. Some have been
based on bad implementations of the JVM, but that's just further
proof that you can't assume Java to be immune from this. The sandbox
is a great idea and drastically decreases the danger... but NOTHING
is a silver bullet.
 
> David Allan Finch
> Certified Sun(tm) Solaris(tm) Admin plus
> C, C++, Java, Perl & JavaScript Programmer.
> Monotype System Development Department
>
> BTW - As we sell system that use Java to our customers
> if you hear of any such virus I would be very grateful
> if you email direct. Thanks for you help in advance.

Maybe you should monitor the Internet for info like this if it means
so much to you.

William E. Kempf


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk