It's also not prone to misleading/inaccurate titles. Did you overlook smoogen's upstream comment? The article clearly states that one of the binaries is what does the "worm" part (i.e., propagation), and his comment identifies said binaries as Linux ones. If that's not the exact definition of "Linux worm," I don't know what is.
Greg, the payload of the "Mare.D" worm (which is really just yet another retread of last year's Lupper/ Plupii/Plupii worm) is only incidentally a Linux x86 ELF binary: Without significant change (and, in most cases without change at all), it could be recompiled for Solaris, *BSD, HP/UX, Mac OS X, Win32, etc.
Calling "Mare" (and Lupper) a "Linux worm" suggests that people running with the exact same, identically exploitable PHPXMLRPC vulnerability on other OS platforms need not pay attention. Does that sound reasonable? And would the exact same exploit code, identical except with the payload compiled for Win32, be fairly regarded as a different "worm"?
In a sense, all of this is actually missing the main point: The real problem isn't "worms", which, after all, are merely automated attack tools against known-exploitable vulnerabilities. The real problem is the underlying vulnerabilities. Any sysadmin who's still running known-remotely-exploitable server-app code by the time the "worms" come out -- inevitably months to years later -- is criminally negligent.
Flaws in user applications that handle public content (Web browsers, MUAs, PDF readers, AV players) concern me a great deal more, frankly. They're more likely to be exposed to danger by completely unwary, security-ignorant people -- as opposed to Web site sysadmins.
Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds