Oracle Voyager Worm Mutated

It looks like the Halloween Oracle Voyager worm has been altered. This new version builds upon the original Voyager worm and extends its functionality. Notice that it's still not perfected, it has some flaws and may barely qualify as a worm. But it does show that it's possible, and that people are working on getting it right. When the original Voyager worm came out, a few of us looked it over quickly and came up with some ways we think it could be fleshed out into a worm; we weren't the only ones. Details courtesy of the Appsec writeup of the new Voyager worm:

In summary, this code does not seem to have implemented a spreading mechanism. As in the previous version, it creates the private database link, but the procedure to spread is missing. The improvements over previous version include the use of a known vulnerability in the VALIDATE_STMT procedure to grant DBA to PUBLIC. The code, with a 1 in 100 chance of execution, implements a Google search for its own code in an AFTER LOGON trigger. The intention is probably to rerun the code at some later point in time. As the subject of the initial posting on Full-Disclosure indicates, the latest version of the the worm code tries to mail the username and password hashes to larry@oracle.com and oracle@

. The last, but important, change from the previous version of Voyager is that it tricks the listener to reset the password for user 'mdsys' to 'mdsys' by abusing the 'set log_file' command. The clear intention is to increase the chances of successfully creating a private link to the database.

Source: New Oracle Voyager Worm Variant, January 4, 2005, Application Security, Inc.

Additional information:

• Oracle database worm mutates, News.com, January 6, 2006.
• 12/31/2005: "More detailed analysis of the new Oracle worm",  Pete Finnigan's Oracle security weblog.
• Oracle Worm Voyager - Analysis of the Proof of concept code, Red Database Security.
• [Full-disclosure] Oracle, kwbbwi at findnot.com, Thu Dec 29 21:15:37 GMT 2005.