🚀 go-pugleaf

Republish At Will ...
On 30 Jul 2000 14:44:13 +1200, Nick FitzGerald 
                  <nick@virus-l.demon.co.uk> wrote:
>David Mohring <heretic@localhost.localdomain> wrote:
>
<<snip>>
>> The Opensource BSD/Linux approach, when the bug is reported back to 
>> the distribution and author, is to rewrite the code removing 
>> the exploitable bug ( the hole in the board ) alltogether. Often reporting
>> the details of the exploit will result in others to go looking for simliar 
>> exploitable bugs in any other open source software that they happen to be 
>> using. New holes are discovered in existing and new applications but 
>> allways it is the original "source" of the problem that is dealt with.
><<snip>>
>
>This is all well and good, but has nothing to do with *viruses*
>(well, "little" to do with them -- viruses *can* but *need not* use
>security holes to do their work).

Actually they have *everything* to do with the *spread* of viruses.
(and a "lot" to do with what interfaces the executing virus has access 
to -- most of the bug fixes found for linux/BSD stop users getting 
root/admin access , limiting the damage a script/executable could to a 
system do if run by a user)

With the one exception of the native code executable trojan run by a user, 
every entry vector that a virus can use to gain entry to a system 
represents the result of combinations of design decisions and 
implimentation flaws. (design flaw,implimentation decision etc )

A lot of exploitable flaws are not discovered until after a system is 
released and just as in the field of cryptography new "cracking" techniques 
are continually being "discovered".

So we cannot expect programmers or vendors to deliver totaly invunrable and
bugless systems ( IMO impossible using current development languages and 
techniques ). BUT we should expect that the vendors who we pay a substantial
amount of money to for a product or service to react quickly once a 
design and implementation flaw is discovered that puts your whole system
at a higher risk of infection or intrusion.

The embedded scripting features within documents represents a class of
virus entry vector that now has been truely "discovered" by all virus 
writers, and because to the relative ease of modification in comparison to 
Assembler/C/C++ coded viruses/trojans, make such virus/trojan writing 
"accessible" to a far larger number people. The probability of 
encountering such a virus is greater and therefore so is the risk of damage
to everything the scripting system grants the script access to.

The unrestricted execution of such scripts by a user "click of assent", 
when the user wishes only to view the content of the object in question, 
represents a big threat, more so via social engineering techniques. We 
should expect be able to view the content of untrusted documents without 
it damaging/infecting our system. 

The unrestricted auto-execution of such scripts without user intervention 
represents the biggest virus explotable *design* *flaw* that a 
program/system can have. NO system or application should ever do 
this - EVER. Even when digitally certified by a "trusted" vendor like 
Microsoft itself ( this has been exploted ). Combine this with the 
application in question having access to the internet via email 
or websurfing - Total F**king disaster - Call Ralf Nader - Ford Pinto
of system design. We should expect better things from companies like 
Microsoft than to even release such products, let alone be so slow
to patch them. 

Social environments change, often for the worst and often more so during 
times of technological change. In most places is not a good thing to 
leave your door unlocked and unfortunally the internet is no different. 
Expected security requirements change and system design and development
must reflect the change to help manage the risk.

>You seem like an intelligent chap, so you should not have too much
>trouble divining the fundamental difference between security exploits
>due to design or coding bugs, and "self replicating code" (i.e.
>viruses) which is a feature of general purpose computers.  Fred Cohen
>said it first, so start with his work.
>

There has been a LOT of work done on Distributed Agents since Mr Cohen 
wrote his original paper back in 1984. 

The a computer (or even a biological ) virus is not alive until an
outside object executes the instructions coded "inside" the virus.
It is probably not possible to prevent virus transmition BUT
there is LOT that can be done to prevent the code inside the virus
from being run, or if run, limiting what the code inside the virus
can do, at least preventing or limiting it's ability to replicate. 

Scripts embedded within documents,email and html that is shared over the 
internet is by default a distributed agent, and represents one virus 
explotable vector that something can be done about.

Organization who allow people to run downloaded or attached native
code executable trojans run a known risk, It is possible by proxy filtering 
and user policy to substantially reduce that risk. BUT documents are 
different, businesses and people share documents over the internet 
all the time.

When people began swaping documents over the internet ( and even before
via floppy disk ) then the scripts embedded inside documents
became Distributed Agents. With the popularity of Microsoft Office the 
assocated file formats have become the business defacto standard, and 
Microsoft itself has promoted the sharing of Office file formats over 
the internet. The problem is that every Office file format ( down 
to the clip art archives ) have the ability to contain scripts.

I do not deny the utility that comes with the ability for Office
documents and templates to do all great things using unrestricted macro 
and basic scripting ( using scripting templates is really useful inside a 
larger organization ). However IMHO I cannot understand why Microsoft 
continues to make the *design decision* to wholesalely grant unrestriced
scripting ability to every document, without requiring the embedded script 
to be digitally signed by person trusted by the user opening the document. 

We no longer *expect* to view web pages with javascript or java applets
and have it intrude/damage/infect our systems. That Microsofts current 
Internet Explorer (and DDLs) fails this criteria is a reflection of
Microsoft's implementation of html frames and jscript (+ASP) rather than 
the design of javascript or java itself.

IMHO Microsoft should also be providing a restricted execution environment
to view untrusted documents, just like viewing an external web page 
with javascript applets. The script execution should not be an all or
nothing choice for the user, putting systems at greater risk by virus 
writers using social engineering techniques.

Microsoft is not alone in producing products with such obvious design
flaws, but the giant dinosaur (truly terrible lizard) of the software 
industry has been one of the slowest to react. IMHO the main reason has 
been because the management of Microsoft has made the conscious decision 
to delegate responsibility for it's products security to a 
third party - the Antivirus industry.

David Mohring - "This is my kind of town."