Slashdot Mirror

CERT Vulnerability Note VU#192371

Writing passwords or authentication tokens to log files is just dumb.
(And makes you wonder about development and review processes at the guilty companies and their customers.)

But what does "store the [authentication and/or session] cookie insecurely in memory" mean? How do you avoid that for DTLS or VPNs that maintain connections transparently as you roam across networks?

This looks like it's been updated since then:

http://www.kb.cert.org/vuls/id...

Previously, solutions were "Replace CPU" or "Apply updates". Now it's just "Apply updates"

The whole thing is overblown. US CERT gave it a CVSS of 1.5 ... which means on a scale from 1 to 10 in severity, it didn't even break a 2.
https://www.kb.cert.org/vuls/i...

Exactly. What is interesting is that Intel apparently got to CERT and made them change their solution from "replace the hardware" to "apply updates". Look at the difference between the two notifications:

Original CERT notification:
https://webcache.googleusercon...

Replaced CERT notification:
https://www.kb.cert.org/vuls/i...

the weakness lies in the protocol's four-way handshake, which securely allows new devices with a pre-shared password to join the network. [...] The bug represents a complete breakdown of the WPA2 protocol, for both personal and enterprise devices

WPA2 enterprise doesn't use a pre-shared key. So which is it? Does the weakness lie with pre-shared key passwords? Or something else which also affects WPA2 enterprise?

Ah, here we go. The answer is "it's complicated." I'm reading through it right now, but as a PSA:

• Here's the original paper on the attack
• Here's CERT's page on the attack
• Here's ICASI's (mostly useless) page on the attack

In the future can we link to original source articles or responses by authoritative organizations, instead of trade rags?

If (and that's a big "if") companies become liable for software failures then it will be most likely that there will be a guideline of standard programming practices. Likely it would restrict companies to using programming languages that have already been heavily analyzed and their security weaknesses identified. CMU has composed guidelines for multiple languages and platforms which could easily be identified programmatically. Such regulation would be a deathblow to companies using script kiddies to scrape together IoT devices in their favorite language du jour but I think we would be better for it. Also, it may also force companies to analyze open source software and (ultimately) submit patches which makes things better for everyone.

I don't know about your country, but in civilised countries we make sure you don't die from eating unhygienic sausages, for example, by making it illegal to sell them, so even consumers that just go for the lowest price are at least somewhat protected.

If the idea of better regulation is going to go anywhere useful, it has to push manufacturers and those along the supply chain towards an achievable better position, and it has to do so with a cost that is commercially viable. I'm not sure that's what some of the people posting in this discussion are asking for.

The standard for food is not that you never ship tainted product. The GP overstated the case when they said they "make sure you don't die from eating unhygienic sausages". The standard for food is that you comply with all applicable safety regulations, and comply with any mandatory recall of any of your products which turn out to be tainted. Ideally you develop a sense about when a recall will be mandatory, and issue one voluntarily before that actually happens. But nobody expects that food will never be tainted. There's no inspection system in the world which would make that possible.

On the other hand, there are no standards being applied before someone can produce software which will communicate on the internet. Perhaps it is time to institute some? Requiring some basic best practices for security (psuedorandomly selected credible search result) would be a start.

OpenBSD

Whoops. Better make sure you're patched.

Microsoft

Yeah, because Windows 10 has no problems parsing strings or managing memory safely or anything.

https://tools.cisco.com/securi...

https://social.technet.microso...

http://www.kb.cert.org/vuls/id...

It's just a harmless protocol - nothing to worry about.

Summary doesn't mention this, but the vulnerability is in libupnp that is used by most of these mobile apps.

UPNP? Well, there's your problem. A protocol that requires zero authentication and has complete trust when it's enabled. What could possibly go wrong?

Summary doesn't mention this, but the vulnerability is in libupnp that is used by most of these mobile apps.

CERT has published the researchers' security disclosure. In case someone wants to read it. http://www.kb.cert.org/vuls/id...

Even better given the likely association with CERT. Unless you still live in the fantasy world where your tech-heavy society is safer when it is full of holes because at least you get to catch a few of the bad guys; pissing the reputation of a major security-research institution down the drain in order to catch a few drug dealers seems like a really terrible plan. There will be more drug dealers tomorrow; but repairing an environment for people to get vulnerabilities fixed without the fear that they'll be stuck in limbo until the feds have finished weaponizing them, then released for fix, will take a lot longer; and leave a lot of important things vulnerable so that the feds can go hunt a few minor threats.

Hi, maybe this will help: http://www.kb.cert.org/vuls/id... and this: http://www.kb.cert.org/vuls/id...

Hi, maybe this will help: http://www.kb.cert.org/vuls/id... and this: http://www.kb.cert.org/vuls/id...

Here's a link to a page that actually describes the "vulnerabilities" they found: http://www.kb.cert.org/vuls/id...

All of them only apply to Voice over LTE environments, which are different from traditional mobile phone networks in that the LTE network is purely IP traffic so it's effectively a voice over IP call using standard protocols like SIP the same as an internet-based VoIP service would.

As someone who's been working in VoIP for over a decade I just have to laugh at this crap.

Let's start:

The Android operating system does not have appropriate permissions model for current LTE networks; the CALL_PHONE permission can be overruled with only the INTERNET permission by directly sending SIP/IP packets. A call made in such a manner would not provide any feedback to the user. Continually making such calls may result in overbilling or lead to denial of service.

Translation: A VoIP app doesn't require phone permissions if it's not accessing any of the OS' phone subsystems. No shit, sherlock.

The only way this could result in billing or denial of service is if the carrier was not properly authenticating the SIP traffic and was just assuming that anything from that phone aimed at the right IP address must be a legit call. That's 100% a carrier fault, not any flaw with the system. Do they propose that Android should be specifically watching for SIP traffic and require an app have the phone permission to be able to send it?

Apple reports that iOS is not affected by this issue.

I smell bullshit, but I don't have an iOS device to confirm. I doubt Apple requires that VoIP clients have special permissions over anything else.

Some networks allow two phones to directly establish a session rather than being monitored by a SIP server, thus such communication is not accounted for by the provider. This may be used to either spoof phone numbers or obtain free data usage such as for video calls.

This is carrier logic if I've ever heard it. Using the data service I pay for to send IP traffic (which happens to contain voice or video) directly to another user on the data service they pay for is somehow a vulnerability? Again I'm not sure how this is platform-specific.

Spoofing numbers again would require that the carrier have their network configured in a stupidly open and trusting fashion. None of my customers can spoof numbers unless I allow them to (hint: I don't) and it wasn't rocket science to set things up that way.

Some networks do not properly authenticate every SIP message, allowing spoofing of phone numbers.

Repeating themselves here, while this time acknowledging that it's the network's problem.

Some networks allow a user to attempt to establish multiple SIP sessions simultaneously rather than restricting a user to a single voice session, which may lead to denial of service attacks on the network. An attacker may also use this to establish a peer-to-peer network within the mobile network.

Well at least this time they blame the network from the start. I wouldn't limit users to a single session, that restricts 3/4 way calls, but reasonable limits are good there. Still not sure what would be wrong with endpoints directly contacting each other via the data service they're paying for.

I have no doubt that some carriers' networks are truly insecure enough to allow the spoofing and fraudulent usage described here, but that's entirely down to their own stupidity because none of these things are hard to prevent at the network level, even the ones that aren't actual problems.

I'm on the side of moving software engineering towards a Profession rather than Unionization.

Right or wrong my impression of unions are that they are catered towards less skilled labor, while professions require a lot more skill that can be encapsulated by many certifications. Lawyers with their bar and accountants with their CPA are examples. I've no doubt many of us can easily come up with a fairly basic curriculum for basic certification - take for example Secure Coding practices. Given how diverse and specialized a lot of our work can be, I imagine a lot of esoteric certificates can be devised. Certifications would likely need to be renewed from time to time as well, considering how quickly technologies and techniques evolve. A profession centered around good education benefits everyone.

From what I have seen, Mitre and NIST often show inaccurate CVSS scores on the CVE pages.

Have to stop you there, sorry for perhaps being a bit pedantic, but the NIST score is more or less the "official" score of a vulnerability, given how closely they work with organizations like MITRE. The CVSS scoring rules have some nuance to them, and in some scenarios the official rules on scoring a vector is not what you'd expect. NIST tries to follow the official scoring rules as strictly as possible. You may not agree with the rules (and many people don't, I'm not trying to knock you), but technically their scores are the most accurate.

CVSS recently released v3.0 scoring in order to try to address some criticisms in scoring. It did this by upgrading its base vector to be a bit more easily comprehensible by adding obvious metrics like "user interaction required", which was previously embedded in "access complexity" in v2. I think in general I like the concepts and it makes it easier for the most part, but time will tell if the general public agrees. The sticking point I think is the idea of scope, which is not a bad idea in general, but the definition seems a little fuzzy to me. We may have only shifted where the nuance is, and so disagreement in scoring may continue into the future.

In order for the metric to be truly useful, every organization has to localize measurement to their environment and each vendor needs to measure impact against their use or non-use of the underlying code. At the end of the day, it's all about risk measurement, but with those steps you end up with a reasonably accurate assessment.

Exactly. CVSS allows for this by use of temporal and environmental scores, but unfortunately, most organizations don't use them. This means most people run around talking about the base score without a clear sense of how it applies to them. I've seen vulnerabilities with a base score of let's say 7.0 or so being knocked down to 1.5, after you factor in its temporal factors (such as a patch being available) and environmental factors (such as not very widely deployed). I wish more people would talk about the environmental factors. CERT is one of the few places that lists temporal and environmental metrics, though their database is not comprehensive.

CVSSv3.0 is weakest in the fact that they essentially threw out the environmental metrics; yeah, its technically there, but its shadow of its former self -- it doesn't include important metrics like population anymore. I hope they will put that back in for CVSSv3.1, and encourage more widespread adoption.

There is nothing wrong with the current system that wider spread adoption and education cannot fix. Part of the problem is the media hype surrounding the bugs. If every little issue wouldn't get a cute name -- Shellshock, Logjam, POODLE -- the reactions might be a little less kneejerk.

I agree, but education can sometimes take a while and be harder than you think. There's momentum -- and money -- behind the current system. You get everyone wound up, and then offer to sell a widget that "protects against it". There's a lot of snake oil for sale in the industry right now, and so far, companies and governments are eating up. It will continue as long as money is being made. The bigger question is, how do you make it more profitable to tell the truth about threats?

Organizations like CERT tend to straight talk it and provide honest feedback with their temporal and environmental scores, but they're not picked up in the media as much as these security start-ups that are out to cause a ruckuss and make money. The start-ups seem to me to be more marketing companies than security companies these days; they tend to overinflate the CVSS base score and talk it up by reaching out to media directly, when in reality, the base score itself may not be that high, nevermind that temporal and environmental factors might lower it more. Fear makes money right now.

Report the vulnerability to CERT.
https://forms.cert.org/VulRepo...
http://www.cert.org/vulnerabil...?

Report the vulnerability to CERT.
https://forms.cert.org/VulRepo...
http://www.cert.org/vulnerabil...?

The Internet of rushed to market, horribly secured, never updated, easily pwn3d things.

Is that a new problem?

(To answer my own question: No, it's not.

If that was true, then they would be working with Microsoft to improve their security, not making it worse by automatically disclosing vulnerabilities when the patch is forthcoming.

I think waiting 90 days for the company whose last CEO said he would "fucking kill" google to fix their shit software is pretty generous.

then I fail to see why Microsoft should have to be beholden to Google's asinine 90-day cut-off when even Google doesn't fix it's security bugs within 90 days in many cases.

Yes, Google's 90-day cut-off is asinine: It's twice CERT's standard, for example. If we really want these bugs fixed, Google should be disclosing them much earlier.

90 days is really long. The US CERT vulnerability disclosure policy is 45 days as described in http://www.cert.org/vulnerabil... (see that more more details). The problem is that you have to balance two conflicting needs; in the words of the CERT, "the need of the public to be informed of security vulnerabilities with vendors' need for time to respond effectively."

It's definitely a fine balancing act, and regardless your opinion on the Google vs Microsoft disclosure debate, I am glad that we are having a public debate about it.

Vulnerabilities cannot really be effectively categorized (look at the attempts from MITRE, for example). Some are due to simple programming errors and can be fixed and rolled out immediately. Some are deeper architectural problems that, even if an "easy" fix, have a whole ecosystem of software built around that wrong behavior. A one-size-fits-all disclosure plan is not necessarily in the public benefit, and I'm glad discussion is being had on what a reasonable timeline looks like, as well as what are extenuating circumstances for changing that timeline.

90 days is really long. The US CERT vulnerability disclosure policy is 45 days as described in http://www.cert.org/vulnerabil... (see that more more details). The problem is that you have to balance two conflicting needs; in the words of the CERT, "the need of the public to be informed of security vulnerabilities with vendors' need for time to respond effectively."

- The disclosure is here:

https://community.rapid7.com/c...

- Vulnerability Note VU#685996 (kb.cert.org):

http://www.kb.cert.org/vuls/id...

I published a note about this approximately 8 years ago: http://www.kb.cert.org/vuls/id...

Yeah, because closed source companies like Microsoft never copy code between versions of Windows, so simple vulnerabilities in things like Windows Metafiles would never affect the security of the entire userbase of Windows 3.0, 3.1, 3.11, NT 4, 2000, ME and XP at the same time. Who knows what other closed source vulnerabilities are lurking out there?

Using goto for error handling in C is a well-established idiom, and is often the best option available. The alternatives either involve deeply nested if statements, or duplicated cleanup code.

For example, this pattern is used quite heavily in the Linux kernel. Linus (and a few others) had had something to say on this matter.

http://search.cert.org/search?client=default_frontend&site=default_collection&output=xml_no_dtd&proxystylesheet=default_frontend&ie=UTF-8&oe=UTF-8&as_q=javascript+&num=10&btnG=Search&as_epq=&as_oq=exploit&as_eq=&lr=&as_ft=i&as_filetype=&as_occt=any&as_dt=i&as_sitesearch=&sort=&as_lq=

The above search at CERT.org has 814 hits for "javascript & exploit" alone.

What more, the remote site would have access to your browser environment until you change to another HTML page, unless they first take advantage of little tricks to stay persistent. The longer they have to poke around your javascript environment the sooner they find the next big bug to hack into the system. All software has bugs, it just a matter of time to find one.

The internet was around long before 1992 "the web" and "gopher", and network security was a serious issue then.

Hell, CERT Advisories were started in 1988. These advisories did not predate the internet, instead they were a response to growing security problems on the internet. In the 1980's most universities in the country were hooked up to the internet, and by the 1990's it was becoming a global standard pushing out the main competitors telenet and tymnet.

This CERT advisory is from 1989 and is a patch for the Berkeley passwd.c.

You appear to be an over-confident nub that doesnt even know the history.

Everyone who cares about correctness of their C or C++ programs at all, should read carefully all of the following articles:

Dangerous Optimizations and the Loss of Causality (PDF)

Understanding Integer Overflow in C/C++ (PDF)

A Guide to Undefined Behavior in C and C++, Part 1 (blog post)

Finding Undefined Behavior Bugs by Finding Dead Code (blog post)

Then complain to your local compiler manufacturer. :P

E-mail is fundamentally insecure. SMTP is easily spoofed because it has no authentication mechanism. By default every message travels unencrypted and nobody bothers to correct that. I can not remember the last time I got an e-mail that was encrypted. Sure gmail may provide me with an ssl connection to read my mail but any message in my inbox could have bounced all over the net in the clear. Every large e-mail provider has been repeatedly hacked. If you have are using a set of insecure protocols with no encryption adding another possibly insecure service doesn't change things much.

What CERT advisory are you talking about? That is a quote from Alex Stamos of Artemis Internet (as it says directly in the article you linked to). The CERT advisory regarding BREACH says nothing about RSA or ECC.

Check your sources. The actual CERT advisory would perhaps be a good place to start.

Historical CERT advisories. Notice the transition from predominantly windows-platform vulnerabilities to predominantly unix-platform vulnerabilities as one goes back in time, to a period where few windows machines were on the internet.

Being open source didnt prevent souce packages like sendmail from being exploited again and again, repeatedly, throughout its history. BSD witnessed vulnerability after vulnerability also.

Description The Oracle Java Runtime Environment (JRE) 1.7 allows users to run Java applications in a browser or as standalone programs. Oracle has made the JRE available for multiple operating systems. The Java JRE plug-in provides its own Security Manager. Typically, a web applet runs with a security manager provided by the browser or Java Web Start plugin. Oracle's document states, "If there is a security manager already installed, this method first calls the security manager's checkPermission method with a RuntimePermission("setSecurityManager") permission to ensure it's safe to replace the existing security manager. This may result in throwing a SecurityException". By leveraging the a vulnerability in the Java Management Extensions (JMX) MBean components, unprivileged Java code can access restricted classes. By using that vulnerability in conjunction with a second vulnerability involving the Reflection API and the invokeWithArguments method of the MethodHandle class, an untrusted Java applet can escalate its privileges by calling the the setSecurityManager() function to allow full privileges, without requiring code signing. Oracle Java 7 update 10 and earlier are affected. This vulnerability is being attacked in the wild, and is reported to be incorporated into exploit kits. Exploit code for this vulnerability is also publicly available.

Older browser version with vulnerability -> JavaScript -> Flash ActiveX -> Java -> sad clown face. Should anyone be surprised? Here's a link to the CERT KB for more information.

Except Intel didn't implement AMD64 correctly 100%. You can read the US-CERT for yourself if you want. For that all you had to do was run a couple of commands and your code could be escalated to kernel level privileges, but only on Intel 64bit. It would be bad to assume that what works on one as an exploit would work the same way on the other. My concern is about this being a flaw in the CPU similar to what happened with Intel 64bit.

This problem has been reported by the US-CERT (part of the US Department of Homeland Security [Insecurity?]) at http://www.kb.cert.org/vuls/id/268267. See that link for an authoritative report on the meaning of this problem and how to avoid it.

Honestly, I think PlusFiveTroll is right, old software will stay as long as physically possible, after which it will move to virtual machines.

I completely agree with this too. I've had success using a webcam through a VM which the host was unable to use because the vendor refuses to release new drivers.

Windows does it wrong, because they break compatibility with every version they release. Then again, that's their business model, and it's making them craploads of money.

Out of all of those operating systems Windows sucks the least (hear me out!). It runs more hardware, has more applications, and is supported far longer. Windows has the best backwards compatibility of any of the popular commercial operating systems out there. Lets see you run a binary from 1998 on a Mac today, Rosetta is being phased out and support for it is lacking in Lion, and not to mention they've switched architectures; or Linux for that matter, good luck piecing together ancient libraries. Your comment is more appropriate directed at their development tools. On the OS side Microsoft has steadily made improvements, most of the woes were from Microsoft enforcing good development practices, (example, see the "Store Application Data in the Correct Location", or Microsoft's general programming guidelines.) why do you think initially many applications required administrator access to run? Sloppy programmers.

Windows doesn't have a monopoly on sloppy programmers. Whether this is due to ease of development or coder competency is a different topic. Sloppy programming plagues companies big and small - just a few months ago ATI had drivers which would BSOD if ASLR and DEP were enabled.

Go here: http://www.kb.cert.org/vuls/html/search/

Type 'Windows XP' in to the search box.

CVE-2012-4681 is a vulnerability that affects Java 7. Apple has only ever provided Java 6 with OS X, and with recent OS X versions, it's not even included by default. So it's pretty silly to make a sensational story that calls out Apple for not addressing CVE-2012-4681 in their update to Java, since they're not even affected by it.

For more details, see: http://www.kb.cert.org/vuls/id/636312

"Yes, this has been true in the past, but perhaps you've noticed plenty of reports on virus issues on macs?"

No. I acn't say that I have. I also Googled for them and the only places I find saying it is a threat are sites trying to sell me antivirus software who don't actually deliver on their promise of listing any. This PC Mag article makes wild claims and then fails to identify a single virus, once again confusing them with Trojans. A search of CERT for OS X Virus turns up nothing but some Windows pages that have OS and version n.n.X in them.

"As a former operating system programmer, listening to someone say they think any machine is virus proof or worth spending extra for because it can't get a virus demonstrates something much lower down on the ladder than balls and stupidity."

As a long time and current systems programmer I would never claim any OS is virus proof. I never did make such a claim. The fact remains that Linux and OS X are far less susceptible to viruses than Windows.

Proper link that ought to have been in the summary instead of that csoonline link (whatever that is):

http://www.kb.cert.org/vuls/id/649219

Wasn't WEP (which has low level encryption, brute forcing can do it) but WPS. A flaw in the protocol makes what should be a hard to guess 8 digit pass-number into two 4 digit pass-numbers, several orders of magnitude easier to crack (brute force)

See: http://www.kb.cert.org/vuls/id/723755

Here's the right one: http://www.cert.org/archive/pdf/CSG-V3.pdf

1. For a business whose computers store and process trade secrets, low paid IT workers are a liability. Someone who is desperate may not need to think twice about selling some trade secrets for two years' salary. CERT even has guidelines for mitigating this threat, though some of this would require an IT guy to configure in the first place (skip to page 63):
   
   http://www.cert.org/archive/pdf/CSG-V3.pdf&sa=U&ei=fmrGT72xCcmX6QHq3dilBg&ved=0CBsQFjAF&usg=AFQjCNEONyDP1ESvK1JeiGPbzIYlGYaoQw
   
   You may not be paying just for skills; you may also be paying for a trustworthy person (and why shouldn't people with impeccable ethics be paid more?).
2. "You work with a computer" is a great way to diminish the value of IT work...until you realize that most people have such a poor understanding of computers that they would be helpless without an IT worker. Most businesses today are dependent on computers, by extension, dependent on their IT staff.
3. The demands placed on IT staff are often very high. How many lines of work expect you to be on call 24x7? How many lines of work demand that you travel to a data center during a snow storm so that you can figure out why some server is down? If you are going to demand these sorts of things from people, it is not at all unreasonable for those people to demand better wages.
4. Not all IT work is as simple as you might think; it is not always a matter of configuring servers and repairing workstations. Some systems are complex, mission critical, and need lots of attention. IT workers can be asked to write a lot of code to extend software or to connect otherwise incompatible programs. The quality of the work done in such cases can be translated into dollars, and mistakes can be very costly as well.
   
   There are also cases of IT guys being asked to clean up some other person's mess. You probably heard this sort of story before: the last IT guy was incompetent, jumped ship or died, and now nobody understands all those perl scripts he wrote to manage the systems. So the new IT guy's first task is to build new management tools, document those tools, and make sure that everyone knows how everything works. That is not a light workload, especially if you are being asked to do it side-by-side with run-of-the-mill IT work, nor is it necessarily simple.

So no, it is not unreasonable for IT workers to complain about $35k/yr salaries. Really, considering how critical IT work can be in a business, I would say that it is risky for a business to hire someone willing to work for such a low salary -- they will either do something corrupt, jump ship and leave you looking for a new IT guy, or they really do not know what they are doing.

Reposted from OSS-Security: http://www.openwall.com/lists/oss-security/2012/05/04/18

Hi,

I guess most of you have heard of this one already, yet it should be in here as well. The original issue was tracked as CERT VU#520827, CVE-2012-1823. PHP 5.4.2 and 5.3.12 were released with an incomplete fix, and apparently CVE-2012-2311 refers to that incomplete fix issue.

http://www.php-security.net/archives/11-Mitigation-for-CVE-2012-1823-CVE-2012-2311.html
http://www.kb.cert.org/vuls/id/520827
http://www.reddit.com/r/PHP/comments/t3pr8/how_serious_is_this/
http://www.reddit.com/r/netsec/comments/t4lxw/phpcgi_query_string_parameter_vulnerability_leads/
http://www.metasploitminute.com/2012/05/cve-2012-1823-php-cgi-bug.html
http://www.opennet.ru/opennews/art.shtml?num=33765 (in Russian)

Alexander

Any sane deployment is not vulnerable as it will not allow telnet or rsh (both insecure protocols). As the US-CERT work-around notes said: ROS users can disable the rsh service and set the number of allowed telnet connections to 0. Disabling the RSH service and setting telnet to 0 effectively disables this remote exploit. I have verified that this exploit works on the latest ROS v3.10.0 release from Oct 6, 2011 for telnet. In my testing, the same "factory" username and password which worked for telnet does not work via SSH or HTTPS services. There may be some other built-in username/password for SSH and HTTPS. Having said that, the ROS switches support multiple VLANs and the management of the switch can be assigned to an isolated management VLAN and restricted from all other access which will further restrict any management access to these devices.

Mass-mailers requiring user interaction are called worms since forever. But many older worms used some form of exploit code, and Melissa was called a virus because it was actually an Office file infector (a macro virus). It's easy to see the reason for confusion.

Love Letter was already being called a worm without exploiting any flaws back in 2000, though*, so was Sircam in 2001 and Bugbear/Thanatos in 2002. By the time Netsky, Beagle and Mimail were around, it was pretty clear a worm was any malware that replicated itself completely over a network and without the use of a host file. When USB drives became common, the term was used for those as well. Floppy viruses infected the boot sector ("infected" being the keyword); malware that spreads over USB just use the Windows autorun function.

Any malware parasite can infect a program that will end up in a USB drive, in the same way that the Parite virus ended up spreading over e-mail when it infected a copy of Beagle (IIRC). A USB worm specifically looks for connected USB drives and copies itself to them. There's a difference.

* http://www.cert.org/advisories/CA-2000-04.html

What people like you do not seem to remember (or maybe you are too young?) is that before Windows had a TCP/IP stack, even before Trumpet Winsock, that Unix and VMS systems were notoriously exploited. Check the history of CERT advisory listings and its nothing but Unix and VMS systems being exploited until a phase change occurred when Windows PC's began to so overwhelmingly dominate the internet.

History proves it. Some of the folks here born before 1975 know this to be true, because we were the ones breaking into Unix and VMS systems because back then. The majority of the internet was Unix so that was what was targeted. Now the majority of the internet is Windows and that is again what is targeted.. and now the owners of these systems are far less sophisticated.