|
|
Home | Switchboard | Unix Administration | Red Hat | TCP/IP Networks | Neoliberalism | Toxic Managers |
| (slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and bastardization of classic Unix | |||||||
| Malware | 2019 | 2018 | 2017 | 2016 | 2015 | 2014 | 2013 | 2012 | 2011 | 2010 |
| 2009 | 2008 | 2007 | 2006 | 2005 | 2004 | 2003 | 2002 | 2001 | 2000 | 1999 |
|
|
Switchboard | ||||
| Latest | |||||
| Past week | |||||
| Past month | |||||
 |
 |
 |
|
|
|
In recent years, Microsoft's designers have deliberately blurred the distinction between opening some data and running a program. To run Word, you no longer have to find the program and execute it. You can run Word indirectly, just by clicking on any Word document, identified by its filename, ending with the three-letter extension .doc. In the same way, if you click on a music file in the .mp3 format, you will execute a music player-by default, of course, Microsoft's own Media Player. The virus executed the Windows Scripting Host because it endedwith the extension .vbs.
Microsoft Responds:
James Gleick's commentary on the "ILOVEYOU" worm ignores some important realities regarding the way software works and the ways people use it.
Perhaps most striking is the implication that viruses in general-and this virus in particular-are somehow specific to Microsoft products. In fact, the most famous incident of this type, the Internet Worm of 1988, spread exclusively through Unix systems, using a mechanism very similar to the one used by the "ILOVEYOU" virus. Even in the case of the "ILOVEYOU" virus, Microsoft products were not the only ones affected; at least two competing e-mail products were affected in exactly the same way as Microsoft's were.
The fact is that viruses can be-and are-written to run on any operating system, using virtually any software vendor's products. Gleick's article seizes upon the fact that this virus would not run on a Unix or MacOS system as proof that there must be a flaw in Microsoft products. But in fact, his statement is simply true by definition-the virus doesn't run on Unix or MacOS because it wasn't designed to. The author of the virus could have designed it to run on those systems but chose not to. Why? Because virus writers tend to be motivated by publicity. Compare the global news coverage that accompanied the "ILOVEYOU" virus with the near-total silence regarding major attacks against competing systems earlier this year, and you can easily see why the virus writer chose to target the systems he did.
People were writing Trojan horses, worms, and viruses for Unix, Macintosh, and other operating systems as back as far as the days of Windows 3.1 and before. They were able to do so because all modern software systems make it easy for one program to call another. Why do these systems do this? Because computers exist to automate tasks. You can't, for instance, integrate your company's invoicing and supply systems unless the systems can communicate with each other. Just the same, it's important to retain checkpoints where human judgment is needed. This is the role that the warning dialogues in Outlook serve-they're a compromise that attempts to give users fair warning without limiting their ability to use their systems.
Gleick nominates a number of design features-the blurring of the line between opening data and running a program, the ability to have more than one file extension, and so forth-as "design flaws" that contributed to the problem. However, none of these are central to the issue. The correct warning dialogues were displayed regardless of how the program was launched, and the correct icon was shown regardless of whether double file extensions were used.
If Gleick would review the history of Outlook's handling of attachments-and Microsoft's approach to security in general-over the past few years, he would see that Microsoft has mounted a vigorous effort to tune the tradeoff between ease of use and security. Our goal is to provide customers with the features they want, along with the security they need. We are continuing to review these tradeoffs on an ongoing basis and will, no doubt, make additional improvements in the future.
-Scott Culp and Steve Lipner
Microsoft Security Response Center
Reader Response from The Fray:
Re: Microsoft's response. Sure, other systems are subject to viral attacks, and, sure Microsoft systems are a big target. But, you fail to address the main points of the article, firstly that Windows blurs the distinction between programs and data, and, secondly and most importantly that any program--regardless of its source--can do what it likes to the system. This is a disaster waiting to happen. And this doesn't affect all systems equally. Linux/Unix limits access for ordinary users, Java has definitive protection from unvetted applications, and so on. Windows security relies on scanning what comes in, using inherently out-of-date virus signature lists. This level of security simply is not appropriate for a computer connected to the internet--if it ever was.
--Jim Birch
(To reply, click here.)
James Gleick has one or two good points, but who can I blame if I stab myself in the head with my brand new shiny Ginsu knife that slices and dices twice as fast? Ginsu promised me the best cutting knife in the world with all the features. What if someone were to attack me with that knife? Am I to blame Ginsu for making a knife so sharp that it's deadly? Should I have stuck with butter knives? What if I drive my safe Volvo with front and side airbags off the meteor crater in Arizona? Will Volvo take the blame? What if I continuously hammer my co-worker over his head with my phone? Damn that Nortel for making such a powerful piece of plastic. If I was smart, I might use the phone cord to strangle him with it. No matter how "safe" a product is, whether it's soft, hard, electronic, pointy, blunt, etc., there's a way to shoot yourself in the foot with it. There's inherent danger in everything.
--Jim F
(To reply, click here.)
Microsoft has chosen to ignore the heart of James Gleick's criticisms. Because they have, I will condense them to a single sentence: Windows Scripting Host gives a Visual Basic script the authority of the user executing the script, not the authority of the author of the script.
Because the script "inherits" the user's privileges, scripts received as attachments, or Visual Basic auto_run VBA procedures received in attached Office documents, can do just about anything the user who opens the document can do. That's why a script can not only make changes to the registry, but it can make changes to registry entries that control scripts. In other words, the registry says "scripts will time out in 10 seconds", and then Windows Scripting Host allows a running script to not only change that setting for all scripts, but for its own running session!
I would like someone at Microsoft to explain why Visual Basic scripts do not inherit the authority of their authors, rather than the person executing them. This strikes me as a fundamental security flaw in their design.
(To reply, click here.)
|
|
|
USENIX ;login June '00
The IT Security Laboratory from the Carlos III University of Madrid was created in 1990, and since these days it has been focused on IT security research and development. Its members have participated in multiple research projects and have worked with a number of companies. They can be reached at <http://benjusuf.uc3m.es/miembros>.
The authors present a general methodology for studying untrusted software that is particularly suitable for the analysis of dangerous software (viruses, worms, and trojans). In many cases, it is useful to learn exactly what untrusted software does on a computer. This methodology is demonstrated with our work on the recent trojan called WinSatan.
|
|
|
Jose Nazario has updated the .cf/.mc patch on his mirror site to include "Killer Resume" and was kind enough to share the fix with us. The patch, designed to block the ILOVEYOU worm and related worm/virus medleys, works on sendmail 8.9.x and above using the subject line checking options available. Koos van den Hout did the original based on last year's Melissa patch, with additions by Nazario and further tweaks by Keith Petersen at army.mil (who also modified the error code to be a 552, as per RFC 821).
It's worth noting that in the long run, header checks are an inadequate solution to this problem for a couple of reasons. First, they can cause email about the virus to bounce (as people on the Bugtraq list quickly realized at the time of the ILOVEYOU worm). Second, there's no reason to think this sort of thing won't continue, which means that the list of offending subject lines will eventually reach absurd proportions.
|
|
|
FlameThrower is a highly configurable add-in for Microsoft's Exchange and Outlook email that scans incoming messages to determine whether they're spam. If they meet the criteria you set, they're moved to a special folder. You can also create a list of senders you want excluded from the spam lists. (Shareware/Win95-98-NT) Click for more.
|
|
|
Re: Invoking procmail from sendmail
Author: Per Hedeland <[email protected]> Date: 2000/05/12 Forum: comp.mail.sendmail
... >I read somewhere that you can invoke procmail from within sendmail. How >do I do that? Does that mean that some filtering can be done in >sendmail? Summarized from another recent thread - this will send all mail through procmail. Put this in your .mc file: FEATURE(`mailertable') MAILER(`procmail') LOCAL_CONFIG CP PROCMAIL LOCAL_RULE_0 R$* $: <> $1 mark all R<> < @ $* > $* $: < @ $1 > $2 skip route-addr R<> $* < @ $* . PROCMAIL . > $: $>3 $1 @ $2 already filtered R<> $* < @ PROCMAIL . > $: $1 already filtered R<> $* < @ $* . > $: <> $1 < @ $2 > remove dot R<> $* < @ $* > $: $1 < @ $2 . PROCMAIL . > send to procmail R<> $* $: $1 < @ PROCMAIL . > send to procmail And in your mailertable: PROCMAIL procmail:/etc/procmailrcs/some.rc .PROCMAIL procmail:/etc/procmailrcs/some.rc See cf/README in the sendmail distribution, and the procmail man page, for further details. You may also want to use MODIFY_MAILER_FLAGS(`PROCMAIL', `+m') or for pre-8.10 sendmail define(`PROCMAIL_MAILER_FLAGS', `SPhnu9m') in your .mc file - this will improve performance by sending mail for multiple recipients through a single invocation of procmail, but makes address-based processing in the procmaillrc trickier. --Per Hedeland [email protected]
|
|
|
Lovebug is a VBScript worm (a worm is a type of self replicating program that does not attach itself to other programs -- so technically speaking it's not a virus, but who cares) that affected mainly users of windows 98 on May 4, 2000 and at least one full subsequent week. Other smaller groups of users that include users of Windows 2000 and beta testers of Microsoft IE5 browser were also hit, but still it looks like this worm was mainly Win98 oriented because this version of Windows was the most mass version that has so called Windows Scripting Host used by the virus (see below).
Like Melissa it spreads via mass mailed e-mail but Melissa limit mailing to the first 50 entries while Lovebug is greedy and mail itself to everybody. This worm is one of the new Melissa-style type of worms that make use of AV program less effective as it mass mail itself on the very first invocation. Therefore if it was not detected at this time it makes little sense to upgrade AV program in order to detect is afterward). But update of AV program when it was most needed proved to be a tricky business. The WEB sites of AV vendors were down due to this denial of service attack. For example McAfee WEB site was the first victim of the worm because is has the most clueless architecture (running on NT) with a lot of scripts, pictures and other bell and whistles died instantly under the load. Semantic site was slightly better and refused to die, but was extremely slow and from practical reasons can be considered as down from 10:00am on May 4th or so. Smaller vendors WEB sites died like flies on the frost. I do not envy people who tried to download, say, an update for F-secure on May 4th.
Actually the most useful source of information were portals that are used to huge traffic and served information all the time -- for example Excite had F-secure description stored locally and was probably the most assessable site with more or less valid information about the virus.
This epidemic also revealed a really bad state of e-mail filtering in some major corporations and ISPs and stressed the importance of filtering capabilities on the mail gateway. Several fixes for Sendmail were published the same day in the Sendmail Usenet group and were also available from Freshmeat the same day. Sendmail that generally is well known for the obscure configuration files provided official patch only on May 5. But it was essentially worse that some files suggested in the Usenet newsgroup. Several e-mail gateway vendors upgraded their products to make filtering easier.
Sendmail proved to be weak -- no patch blocking .vbs attachments was available during the week after the discovery of the virus. Exchange and Lotus Notes proved to be weak too from this point of view as well. Sendmail installtions that use Procmail were probably the only one that come out of this situation with flying colors, but very few people know how to use Procmail as a standard MDA with sendmail.
Procmail come out of this situation with flying colors
Here is the procmail fix from Tomas Andershem
:0 B * !^FROM_DAEMON * !^X-Loop: viruscheck * ^Content-Disposition:.* * .*.vbs.* | (formail -rI"Precedence: Virus" \ -A"X-Loop: viruscheck" ; \ echo "Our system received your mail,"; \ echo "but it found something that indicated a virus."; \ echo "and did not delivered this mail"; \ echo "Please do not respond to this mail, it is an auto reply"; \ ) | $SENDMAIL -oi -t
The worm actively spread itself until at least May 11. Actually Monday May 9th was worse than Friday May 5 for some US regions.
|
|
|
The mutation comes in an email with the subject header "VIRUS ALERT!!!" The email begins, "Dear Symantec customer," and proceeds to describe the virus in detail. Its attachment is called "protect.vbs."
This variant overwrites *.bat and *com files, in addition to the image and audio files already overwritten or hidden by the original "Love" bug.
| c | FWD: JOKE |
VERYFUNNY. vbs |
yes |
| d** | I Love You |
LOVE-LETTER- FOR-YOU.TXT. vbs |
yes |
| e | Mother's Day Order Confirmation |
mothersday. vbs |
no |
| f*** | Dangerous Virus Warning |
virus_warning. jpg.vbs |
yes |
| g**** | VIRUS ALERT!!! | protect.vbs | yes |
| h***** | A killer for VBS/LoveMail and VBS/Kak worm | viruskiller.vbs | yes |
[May 5, 2000] sendmail.net lovefix -- See also Sendmail - Alert - Blocking Feature for Love Bug Extremely weak clueless patch. I am convinced that the best approach to the fighting lovebug is blocking *.vbs attachments but stupid filtering of the subject lines proposed. But instead of developing a decent patch Sendmail tries to be nice with AV vendors (see below ;-).
L OCAL_RULESETS
# Love Letter virus checking routine.
# You just need enough of a pattern to match.
# Instructional note: Follow these instructions exactly
# The format for the rule is
#
# RExactly the thing you want to quote
#
# No quote marks, no tabs, absolutely nothing in
# parentheses (like this, they're considered comments
# and will be removed before they get to the rules).
# After the exact thing, then a tab, and the $#error.
# Note, the $* matches anything, so it's useful for
# wildcarding. This also scans all messages with
# Subject: headers and invokes a rule, so there is
# a performance hit.HSubject: $>Check_Subject
D{MPat}ILOVEYOU
D{MMsg}This message may contain the LoveLetter virus.SCheck_Subject
R${MPat} $* $#error $: 550 ${MMsg}
Another sign of questionable usefulness of Sendmail
Emeryville, CA - February 29, 2000 - Sendmail, Inc., the provider of the ubiquitous Sendmail® Internet Mail platform for e-communications, applications and services, today announced a powerful new framework for easily and reliably preventing Internet-borne viruses from infecting corporations and service providers. Sendmail, Inc. is now providing API access for industry-leading anti-virus vendors such as Symantec, Trend Micro and Network Associates to deploy their solutions at the server-level on the Sendmail Switch product line. Integrated server-level virus scanning is a much faster and more flexible approach to protection that eliminates viruses before they reach the desktops of the end users.
|
|
|
|
|
|
|
|
|
|
Technical director of Symantec Anti-Virus Europe Kevin Street stresses that even though it is impossible to infect a computer running Linux with a Windows virus, this doesn't mean Linux is totally immune to them. "Even thought a Linux mail server cannot be infected, it doesn't mean it wont be affected. The amount of mail it could receive might mean that it is brought down and even though your company is immune, you have no email."
|
|
|
http://www.securityportal.com/
Anti-virus software
Entire classes of software with literally hundreds (ok, maybe not hundreds but a lot) of companies producing products have sprung up over the last few years, and is now beginning to consolidate into several large companies providing complete product lines to cover everything you could want, and dozens of medium to small sized companies with sometimes just one main product. Of this the anti-virus software vendors were one of the original groups of vendors to start writing add-on software to enhance the security (which was non-existent on Microsoft platforms at the time) available for ensuring software that you used was not malicious. This has lead to an "arm's race" (apologies for using this but it is a decent analogy) between virus software writers, and anti-virus vendors. Most anti-virus software packages started out as simple programs that checked the files against a known list of "bad" ones (i.e. via checksum and so forth), which lead to polymorphic viruses (that is the software would modify itself a little bit each time, thus defeating this detection technique). The anti-virus vendors then started scanning the actual binary code for the various pieces of code present in viruses, and heuristic packages that supposedly figure out what the software will do, and based on that can block it if it is considered malicious (if this worked properly though we wouldn't be needing anymore virus signature updates now would we?). Additionally things have gotten more complicated, with the integration of anti-virus software with such services as email, www and ftp. A small list of "new" problems with anti-virus software that have come out in the last few months:
- compression of the virus with a little used compression algorithm successfully fooled most anti-virus packages (this was fixed in most of them)
- compression of the virus with some XOR'ing of the data, successfully fooled most anti-virus packages
- storing the virus in directories not scanned by the anti-virus software, such as "Recycle bin" in windows (user can configure the software to scan that directory usually)
- exploitation of various buffer overflows in software packages like Outlook so that the virus is run without the user actually being asked if they want to save or run the attachment (fixed)
- usage of system calls and software in Windows, such as having Outlook email everyone in your address book a copy of the virus
- addition of some characters to the attached file successfully fooled email anti-virus packages
That's all I could find from the last month or two of Bugtraq. Obviously the anti-virus vendors have a ways to go before their products can even be called remotely reliable. The last dozen or so viruses that spread via email have all left the anti-virus vendor community flat footed, the Melissa virus (which was relatively harmless) resulted in several large sites (Microsoft, Intel, etc.) shutting down the mail servers (and in some cases it overwhelmed mail servers causing them to be effectively shut down).
It is obvious that anti-virus vendors will always be playing catch-up with the virus writers, which wouldn't be such a problem if anti-virus software updates were released quickly and people installed them. This is however impossible. The life cycle of a virus looks something like:
- virus is written, tested, possibly deployed on a test network (computers are cheap now) and otherwise honed
- virus is released, possibly on a selected target (university campus, corporate network, etc.)
- virus (if "successful" in a biological sense) spreads like wildfire, possibly causing severe damage (such as wiping motherboard BIOS chips)
- someone notices the strange activity, takes whatever data is left over, and sends it to an anti-virus vendor - this is the first point at which people start taking corrective steps, the virus has already had time to spread
- the virus is analyzed, decompiled, and otherwise ripped apart, a signature is created
- typically the anti-virus vendor will share data with other competitors, they may or may not do this promptly
- the anti-virus vendors issue bulletins, make the update (if one exists yet) available
- some customers with support contracts and so on will be notified, some will have automated distribution systems for the update, resulting in a rapid deployment of the fix, most will not
- network and system administrators, home users, and so on possibly read the advisory or hear about the virus on CNN, they get the update (which can be near impossible during peak times) and install it
During steps 2, 3, 4, 5, and up till 6 the virus will spread unchecked. Once an update is created and distributed the virus will only spread to systems without protection (a good sized percentage). The amount of effort it takes to install software on millions of computers is horrendous, even when heavily automated, compared to the amount of effort a virus author spends, the ROI (return on investment) can be significant.
Google matched content |
...
Society
Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers : Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism : The Iron Law of Oligarchy : Libertarian Philosophy
Quotes
War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda : SE quotes : Language Design and Programming Quotes : Random IT-related quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes
Bulletin:
Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 : Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law
History:
Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds : Larry Wall : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting Languages : Perl history : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history
Classic books:
The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite
Most popular humor pages:
Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor
The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D
Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
|
|
You can use PayPal to to buy a cup of coffee for authors of this site |
Disclaimer:
The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.
Last modified: March, 12, 2019
