Vesselin Bontchev

← All papers

Star What?

[Bontchev06d] Virus Bull., August, 2006, pp. 7–11.

Dr. Vesselin Bontchev, anti-virus researcher
FRISK Software International
Thverholt 18, IS-105 Reykjavik, Iceland
E-mail: bontchev@complex.is

1 Introduction

On 30th of May, 2006, a short message appeared on Kaspersky Labs’ web log ([KAV06]), announcing the appearance of a new macro virus for StarOffice. “I came across something interesting today,” wrote the poster, “a macro virus which we’ve named Virus.StarOffice.Stardust.a.” And also: “But if you look more closely at the name, you can see why I'm interested: Stardust is a macro virus written for StarOffice, the first one I’ve seen. Macro viruses usually infect MS Office applications.”

Now, we all know that the anti-virus researchers all over the world are overloaded by the continuous glut of new malware and the constant stress often causes them to make silly mistakes. Especially in such a quick-and-dirty publication like a blog – it’s not a scientific paper and one could expect that the author hasn’t done extensive research and fact-finding before posting such a short message… Still, how many mistakes are likely to be found in the above?

To begin with, the name StarOffice is unnecessarily restrictive. This is the name of a commercial product made by SUN and based on the code base of OpenOffice – an open source product ([SUNFAQ]). Any malware supposedly written for StarOffice would work under OpenOffice too.

Second, OpenOffice is too generic to be used as a proper malware platform name. According to the CARO Malware Naming Scheme ([CARO]), one should use either the language in which the malware is written (i.e., StarBasic in this case) or the application for which the virus is specific (e.g., StarWriter).

There are more mistakes in the above announcement but, in order to find them, we needed a sample of the thing, so that we could research it. So, we requested one.

Almost half a decade ago, the author of this article did some research into the “virusability” of this platform. Way back then, OpenOffice supported a single macro language, called StarBasic, which was somewhat reminiscent of VBA but the two languages were not compatible. OpenOffice was able to open Microsoft Office documents – including documents that contained macros – but during the conversion process the macros were simply stripped from the document. In addition, StarBasic did not seem to have the concept of “self” – it didn’t seem possible for a StarBasic macro to say “copy myself from here to there”.

Of course, that did not mean that viruses for the platform were impossible. The language was powerful enough to implement several kinds of them without the capability of copying macros from one document to another. For instance, it was possible to implement mass-mailers, it was possible to implement overwriters, and it was possible to implement viruses that copied the data of the target document to themselves and then overwrote that document – pretty much like the Jinni.A virus does in MS Excel ([VB2005]). OpenOffice also conveniently allowed any macro subroutine to be attached to any “event” – like a menu selection or a keypress. Still, it didn’t seem likely that such viruses would have a significant chance to spread and become a problem.

Sadly, meanwhile the things have “improved” a bit. Nowadays, OpenOffice supports several different languages – StarBasic, BeanShell, Python and JavaScript. They are all script languages, however – not macro languages, which leads us to another error in the original announcement. Whatever the new thing was, it couldn’t have been a macro virus; at best, it was a script virus.

In addition, the StarBasic language has become much more powerful too. We became aware long time ago that full-featured viruses for it were possible; see, for instance, [Rautiainen]. So, the news that someone has, allegedly, finally made a virus for it was hardly a surprise. For more information, though, we had to wait for a sample, so that we could analyze it.

2 Not Another First

Finally, we got our sample. It arrived in an archive, containing three samples. One of them was in a subdirectory named Dropper, so, supposedly, it contained the first generation of the virus. The other two were, also supposedly, infected documents.

The files that contained the samples all had the SXW extension – in other words, they were StarWriter documents. Initially, we did not enjoy the perspective of having to reverse-engineer yet another silly, undocumented file format. (We have had more than enough reverse-engineering silly undocumented file formats used by the various Microsoft products, thank you very much.) But then we remembered that OpenOffice uses a different concept. The format there is really “open” - the “document” there is essentially a ZIP archive, containing various XML files in various subdirectories. The idea is, apparently, so good that Microsoft, allegedly, intends to steal/borrow/innovate it in their next version of Office.

So, the contents of an OpenOffice document is really easy to take apart. It took us just a few seconds to find the XML file that contained the “macros virus” code.

Now, the author of this article doesn’t claim to be a StarBasic expert, but things immediately started looking fishy to him. The code contained three subroutines – AutoInstall, mygame and InstallGlobalModule. The first just called the second. It already looked strange, because “AutoInstall” is not a special subroutine name in StarBasic (e.g., as “AutoOpen” is in WordBasic or “Auto_Open” is Excel’s version of VBA). But let’s assume that the subroutine does manage to get invoked somehow – maybe it was attached to an often-called event or something.

The next problem was in the subroutine mygame. It began with the comments

'*******************************
'******* OOo.Stardust    *********
'*** (c)by Necronomikon[DCA] ***
'*******************************

and ended with, apparently, a call to InstallGlobalModule:

' InstallGlobalModule()

Now, one does not have to be a StarBasic expert, in order to realize that there is no way the above could work. As is obvious from the first few lines, the sequence “'” is clearly a comment – a notion supported by the fact that it resolves to the “'” (apostrophe) character in XML and in most Basic dialects this character is used to indicate that what follows (till the end of the line) is    comment. So, apparently, the call to the InstallGlobalModule subroutine (which seemed to contain the bulk of replication code) is commented out – i.e., the replication is never invoked!

A discussion with some other CARO members (e.g., [Raiu]) confirmed that the thing was unable to replicate – i.e., it was not a virus but an Intended. Here we have yet another error in the original announcement, which claims that it is a virus. Admittedly that announcement also said “Stardust is the first virus I know of which is theoretically capable of infecting StarOffice…”, so it could be argued that it was talking about a potential, not a real virus. The author of this article finds such an argument pretty bogus, though – the rest of the announcement quite unambiguously calls the thing a “virus” and it never says explicitly that it simply doesn’t work.

As we shall see in the next section, though, Kaspersky Labs are far from the only ones who have made this mistake.

3 Amazing Incompetence

The alleged author of this thing, the guy who uses the handle Necronomicon, is well-known to us from the macro malware world. Well known for his incompetence and ineptitude, that is. He is the author of several macro Intendeds, like Delay.A, Gamor.A, Hilite.A, Hilite.B, Hilite.C and Hilite.G. For those who came late to the party, an “intended” is a program written with the obvious intent to make a virus but which is too buggy to replicate. It’s a double joke on its author – not only was he too incompetent to create a working virus (a rather trivial task, especially in the macro and script worlds), but was also stupid enough to release it without even trying to run it even once (otherwise he would have noticed that it doesn’t work). People who release many such things (not just one) demonstrate a particular lack of the little thing that makes the difference between the human and the chimp – and I’m probably offending the chimps.

But the commented out call to the replication routine is by far not the only problem of this thing. Even if the comment is removed, it cannot be made to work. The observant reader would notice, that then the subroutine is invoked without any parameters. But the declaration of this subroutine, just a few lines below, clearly indicates that it is supposed to take one mandatory and two optional arguments:

Sub InstallGlobalModule( ByVal cGlobalLibName As String,_
Optional cDocumentLibName,_
Optional stardust )

The code after that relies on the presence of the first argument and tries to take some reasonable action if the two optional ones are missing:

If IsMissing( cDocumentLibName ) Then
cDocumentLibName = cGlobalLibName
EndIf
If IsMissing( stardust ) Then
InstallGlobalModule2( cGlobalLibName, cDocumentLibName, BASIC_MODULE )
InstallGlobalModule2( cGlobalLibName, cDocumentLibName, DIALOG_MODULE )
Else

Apparently, the subroutine is supposed to perform some kind of generic module copying function and to copy a given module to different places, depending on how the subroutine is invoked. But since it is never invoked correctly, we can’t know that for sure. It sure looks as if the malware author has taken this subroutine from somewhere without really understanding what exactly it is supposed to do and how it is supposed to be called.

But it gets even worse, folks. Apparently, the procedure InstallGlobalModule2 is not part of the standard OpenOffice installation ([FitzGerald]) – and it is not present anywhere in the code of the “virus”, either. So, even if the replication function was invoked correctly, it would fail to work, because it is referring to a non-existing subroutine. The code just immediately after the one quoted above also calls a function named DoesModuleExist – which, too, is not part of the of the standard OpenOffice installation and the implementation of which cannot be found anywhere in the code of the sample we got.

In other words, there was absolutely no way the code we were looking at could be a virus. It didn’t have just some trivial bug that could be fixed, either – it looked more like a random collection of code, the author of which didn’t really understand what that code was supposed to do.

Then we turned our attention to the so-called “dropper”. Maybe, we thought, the dropper has the capability to infect documents once, but the code is incapable of propagating for more than one generation – e.g., because some important part of it isn’t copied around after the first time. However, even a cursory inspection of the code of the “dropper” proved that this couldn’t be the case. Furthermore, there was absolutely no way the “dropper” could have produced the code in the other two samples.

When comparing the code of the “dropper” with that of the other two samples, we discovered only two differences. One of them was that they began with two different sets of declarations. The “dropper” begins with

Dim lAutoInstall as Boolean
Dim Url As String
dim myFileProp as Object

while the code in the “samples” begins with

Const GLOBAL_LIBRARY = True
Const DOCUMENT_LIBRARY = False
Const DIALOG_MODULE = True
Const BASIC_MODULE = False
Dim lAutoInstall as Boolean

Now, there is no obvious reason why the code should change like this. There are no operators that attempt to modify these lines at the beginning. However, in VBA, the source of the module often begins with a series of Attribute statements. These don’t generate any p-code and can change when a module copies itself from a document to the global template (and under several other circumstances), so we decided to give this difference the benefit of doubt – maybe it was somehow produced automatically by OpenOffice.

The second difference, however, was clearly put there by the malware author and there was absolutely no natural explanation for its absence in the supposed “replicants”. The difference is that just before the commented-out call to InstallGlobalModule, the “dropper” contains the following lines:

otext=oDocument.text
ocursor=otext.createtextcursor()
otext.insertString(ocursor, "***Stardust***(c)by Necronomikon[DCA]",false)
url=converttourl("http://stardustvx.tripod.com/SilviaSaint.JPG") 'nice idea from Slagehammer... ;)
oDocument = StarDesktop.loadComponentFromURL(url, "_blank", 0, myFileProp() )

These lines attempt to download a file and to display it on the desktop. Since there was no natural explanation for their absence in the “replicants”, the only reasonable conclusion was that, in reality, we weren’t looking at a dropper and replicants of the virus it drops – we were looking at two different variants of non-viral malware.

Now, one incompetent malware author is hardly a surprise – among them, ineptitude is rather the rule than the exception. What is surprising, however, is how many supposedly competent anti-virus companies have just believed his claims (or have copied each other’s descriptions) and have described these two different things as a single virus for OpenOffice. And it wasn’t just Kaspersky Labs, oh no.

“The Stardust virus doesn't appear to work very well” says Sophos’ Graham Clueley ([Sophos]). “Not very well”, huh? Hey, Graham, how about not at all?

“We have a sample of a proof-of-concept macro-virus for OpenOffice.org” writes F-Secure’s Sean in their blog ([FS2006]). Sean, OpenOffice.org is a web site and this thing is neither macro, nor a virus. It’s an intended script.

“Type: virus” has written somebody from Computer Associates in their description of this thing ([CA]). Nope, folks, it ain’t.

“SB.Stardust.A!int is a proof-of-concept macro virus for Sun StarOffice documents”, says Symantec’s description ([Symantec]). It’s not a virus, folks! Well, at least you get brown points for appending “int” at the end of the name, suggesting that it’s an Intended. But why not say so clearly in the description? (McAfee use a similar approach – they use “.intd” in the name but are shy of stating clearly in their description that the thing doesn’t really work at all.)

“It is the first time that the experts detected a macro virus called “Stardust” in internet, which takes advantage of the Office-Suite OpenOffice for its attack. The moment the user opens the document template, the script that was written in StarBasic will infect all the following documents”, boldly claim the guys from Avira ([AVIRA]). Guys, your so-called “experts” aren’t.

SoftWin’s scanner calls the thing “Worm.StarOffice.Stardust.A”. A worm?! Now, I know that the experts can never agree what exactly the definition of a worm is, but I didn’t know that you were supposed to call that a horribly buggy piece of non-working code that doesn’t even run, let alone replicate, let alone replicate over networks.

Trend, seemingly, couldn’t make up their mind about what the thing really does ([Trend]). On the one hand, their description says, “Once an infected document is opened, it downloads and opens an image of an actress from a certain Web site. It then proceeds to infect other StarOffice/OpenOffice Suites document files”, which is clearly false. But then it adds, “However, due to some errors in its code, it cannot perform its infection routine”. Good job! But why, then, guys, does your description say “In the wild: Yes”?! In the wild?! This non-working thing?! No way! In the wild imagination of the journalists, maybe.

Doesn’t anyone analyze the stuff they receive these days?! That makes me feel old…

And that’s just the anti-virus companies, folks, the ones that are supposed to know better. What can we say about the popular computer press that has never been distinguished with competence in this (or any other) area? And, indeed, PCWorld, ZDNet, News.com, InfoWorld, and all the rest have jumped on the “Stardust virus lands on OpenOffice” bandwagon. Duh!

In fact, even the official response of OpenOffice.org to this “threat” ([OOO]) calls it a “virus”. And although they do say that “technically, it is not even a virus, as it is not self-replicating”, they also add “with OpenOffice.org’s default settings, it cannot spread without user intervention”. Folks, the only kind of “user intervention” that would make this thing “spread” is taking the module it resides in and copying it manually elsewhere. But, with that kind of “user intervention”, even the “Hello world” macro is a “virus”. One would have hoped that at least the guys at OpenOffice.org are capable of reading and understanding StarBasic – but, nope, apparently not.

4 Stage Three

At this stage, a private communication ([Szappanos]) from Szappanos Gabor, a Hungarian anti-virus researcher working for VirusBuster, turned my attention to the fact that the author of this malware seems to have borrowed the InstallGlobalModule subroutine from a publicly available package of macros ([LibInst]).

Indeed, if you look there, you’ll find not only the InstallGlobalModule subroutine but also implementations of the missing InstallGlobalModule2 and DoesModuleExist. It became clear that the author of the thing had seen this library but had been unable to understand how it works exactly and why – only that it seems to have the ability to copy modules around. So, he has tried to copy the relevant parts from it, but being unable to determine which parts were relevant and how they are supposed to be used, has messed up. Badly. But, being an impatient kid (aren’t they all), he has rushed to send his “creation” to all the anti-virus companies and get his 15 minutes of fame. Fame, of which he has received more than deserved, mostly due the incompetence of the popular media and of the said anti-virus companies.

But, apparently, he had a nagging feeling that his creation isn’t quite perfect, to say the least. So, he has continued to “improve” it and has released yet another (third) variant. Sadly, he again has forgotten to test whether the thing actually works or at least to read the documentation of StarBasic, because the third variant is again an Intended.

The main difference this time is that he has lifted also the function DoesModuleExist from the public macro library mentioned above. He has also changed all calls to InstallGlobalModule2 to just InstallGlobalModule – because he still hasn’t taken the former subroutine from the macro library. Sadly, these calls are all inside a subroutine named InstallGlobalModule too – which would normally lead to infinite recursion and a crash. If that subroutine were called at all, that is. Because, folks, it isn’t. Not even a commented-out call – nothing at all. Just how stupid people can be?!

5 The Name of the Weed

So, no, we still don’t have any viruses for OpenOffice yet, no matter what the hysterical media and the incompetent anti-virus companies are claiming. Still, we do have some malware for it (three Intended variants), so we needed a name for the platform in the CARO Malware Naming Scheme, as well as a family name for the trinity of variants.

Strictly, speaking, StarBasic is a script – not a macro language, since it is just ASCII text and is not tokenized or compiled in any way. So, we felt that StarBasicScript (or SBS for short) would be the proper platform name. However, in the name of brevity, we decided to use just StarBasic (or SB for short) instead.

As for the family name, there were proposals for Bulldust or Dustar, but the name “Stardust” picked by the malware author was so widely hyped by the media, that we decided to go with it, in order to avoid additional naming confusion.

So, the full names of the three variants are:

intended://StarBasic/Stardust.A

intended://StarBasic/Stardust.B

intended://StarBasic/Stardust.C

6 Conclusion

Yes, OpenOffice is a virusable platform – it is perfectly possible to write a virus for it. No, nobody has done that yet. At the time of writing of this article (June 2006), there are only three non-working things written by somebody who obviously has more time than brains.1

In that aspect, we would suggest that “Necronomikon” changes his handle to “Necromoron” – from the Greek “necros” (“dead” – as in “brain-dead”) and the English “moron” (“dolt”). We feel that the latter handle more aptly reflects his mental abilities.

References