Macro and security
Security risks due to using software macros are numerous. This article describes some known issues.
C preprocessor text substitution risks
[edit]Text substitution via a feature like the C preprocessor macro has a relatively high risk of causing a software bug as compared to other programming constructs.[1][2]
Hidden multiple evaluation
[edit]Consider the common definition of a max macro:
#define max(a,b) (((a) > (b)) ? (a) : (b))
The expressions represented by a and b are both evaluated two times due to macro expansion, but this aspect is not obvious in the code where the macro is referenced. If the actual expressions have constant value, then multiple evaluation is not problematic from a logic standpoint even though it can affect runtime performance. But if an expression evaluates to a different value on subsequent evaluation, then the result may be unexpected. For example, given int i = 1; j = 2;
, the result of max(i,j)
is 2. If a and b were only evaluated once, the result of max(i++,j++)
would be the same, but with double evaluation the result is 3.
Hidden order of operation
[edit]Failure to bracket arguments can lead to unexpected results. For example, a macro to double a value might be written as:
#define double(x) 2 * x
But double(1 + 2)
expands to 2 * 1 + 2
which due to order of operations, evaluates to 4 when the expected is 6. To mitigate this problem, a macro should bracket all expressions and substitution variables:
#define double(x) (2 * (x))
VBA macro risks
[edit]A risk with using VBA macros, such as in Microsoft Office applications, is exposure to viruses.[3][4]
Risks stem from factors including ease of writing macros which decreases the skill required the write a malicious macro and that typical document sharing practices allow for a virus to spread quickly.[5]
- System macro virus
A system macro – one that provides a core operation – can be redefined. This allows for significant flexibility, but also is a risk that hackers can exploit to access the document and its host computer without the user's knowledge or consent. For example, a hacker could replace the built-in core functionality macros such as AutoExec, AutoNew, AutoClose, AutoOpen, AutoExit with malicious versions.[5] A malicious macro could be configured to run when the user presses a common keyboard shortcut such as Ctrl+B which is normally for bold font.[5]
- Document-to-macro conversion
A type of macro virus that cuts and pastes the text of a document in the macro. The macro could be invoked with the Auto-open macro so that the text would be re-created when the document (empty) is opened. The user will not notice that the document is empty. The macro could also convert only some parts of the text in order to be less noticeable. Removing macros from the document manually or by using an anti-virus program could lead to a loss of content in the document. [4]: 609–610
- Polymorphic macros
Polymorphic viruses change their code in fundamental ways with each replication in order to avoid detection by anti-virus scanners.[6]
In WordBasic (first name of the language Visual Basic), polymorphic viruses are difficult to do.
Indeed, the macro's polymorphism relies of the encryption of the document. However, the hackers have no control of the encryption key.
Furthermore, the encryption is inefficient: the encrypted macros are just in the document, so the encryption key is too and when a polymorphic macro replicates itself, the key does not change (the replication affects only the macro not the encryption).
In addition to these difficulties, a macro can not modify itself, but another macro can. WordBasic is a powerful language, it allows some operations to the macros:
- Rename the variables used in the macro(s).
- Insert random comments between the operators of its macro(s)
- Insert between the operators of its macros other, ‘do-nothing’ WordBasic operators which do not affect the execution of the virus.
- Replace some of its operators with others, equivalent ones, which perform the same function.
- Swap around any operators the order of which does not impact the result of the macro’s execution.
- Rename the macro(s) themselves to new, randomly selected names each time the virus replicates itself to a new document, with the appropriate changes in these parts of the virus body which refer to these macros.
So, in order to implement macros viruses which can change its contents, hackers have to create another macro which fulfills the task to modify the content of the virus. However, this type of macro viruses is not widespread. Indeed, hackers frequently choose to do macro viruses because they are easy and quick to implement. Making a polymorphic macro requires a lot of knowledge of the WordBasic language (it needs the advanced functionalities) and more time than a "classic" macro virus. Even if a hacker were to make a polymorphic macro, the polymorphism needs to be done, so, the document needs to update and the update can be visible to a user.[4]: 610–612
- Chained macros
During replication, a macro can create do-nothing macros. But this idea can be combined with polymorphic macros, so macros are not necessarily do-nothing; each macro invokes the next one, so they can be arranged in a chain. In such a case, if they are not all removed during a disinfection, some destructive payload is activated. Such an attack can crash the winword processor with an internal error. Since Winword 6.0, the number of macros per template is limited to 150, so the attack is limited, too, but can still be very annoying. [4]: 623
- "Mating" macro viruses
Macro viruses can, in some cases, interact between themselves. If two viruses are executed at the same time, both of them can modify the source code of each other.
So, it results a new virus which can not be recognize by the anti-viruses software. But the result is totally random: the macro virus can be more infectious or less infectious, depending upon which part of the virus has been changed.
However, when the 'mating' is unintentional, the resulting macro virus has more chances to be less infectious.
Indeed, in order to replicate itself, it has to know the commands in the source code, but, if it is changed with a random scheme, the macro can not replicate itself.
Nevertheless, it is possible to do such macros intentionally (it is different from polymorphic macros viruses which must use another macro to change their contents) in order to increase the infectivity of the two viruses.
In the example of the article,[4]: 612–613 the macro virus Colors[7] infected a document, but another infected the user's system before : the macro virus Concept.
Both of these viruses use the command AutoOpen, so, at first, the macro virus Colors was detected but the command AutoOpen in it was the command of the macro virus Concept.
Moreover, when Concept duplicates itself, it is unencrypted, but the command in the virus Colors was encrypted (Colors encrypt its commands).
So, replication of the macro virus Concept results in the hybridation of this macro virus (which had infected the user's system first) and Colors.
The "hybrid" could replicate itself only if AutoOpen were not executed; indeed this command comes from Concept, but the body of the hybrid is Colors, so that create some conflicts.
This example shows the potential of mating macro viruses: if a couple of mating macro viruses is created, it will make it more difficult to detect both macro viruses (in this hypothesis, there are only two viruses which mate) by the virus-specific scanners and may reinforce the virility of the viruses.
Fortunately, this type of macro virus is rare (more than the polymorphic macro viruses, one may not even exist), indeed, creating two (or more) which can interact with each other and not reduce the virility (rather reinforce it) is complicated.
- Macro virus mutators
Among the worst scenarios in the world of viruses would be a tool allowing one to create a new virus by modifying an existing one. For executable files, it is hard to create this kind of tool. But it is very simple for macro viruses since sources of macros are always available. Based on the same idea of polymorphic macros, a macro can perform modifications to all macros present in the document. Considering this, there are just a few modifications to make to the macro in order to convert it in a macro virus mutator. So it is easy to create macro virus generators, and thereby to create quickly several thousands of known viruses. [4]: 613–614
- Parasitic macro viruses
Most macros viruses are stand-alone; they do not depend on other macros (for the infectious part of the virus, not for the replication for some viruses), but some macros viruses do. They are called parasitic macros.[4]: 614–615 When launched, they check other macros (viruses or not), and append their contents to them. In this way, all of the macros became viruses. But, this type of macro can not be spread as quickly as stand-alone macros. Indeed, it depends on other macros, so, without them, the virus can not be spread. So, parasitic macros often are hybrid: they are stand alone and they can infect other macros. This kind of macro virus poses real problems to the virus-specific anti-virus; in fact, they change the content of other viruses, so that accurate detection is not possible.
Suboptimal anti-virus
[edit]There are different types of anti-virus (or scanners), one is the heuristic analysis anti-virus which interprets or emulates macros.
Indeed, to examine all branches of macros require a NP-complete complexity[4]: 605 (using backtracking), so in this case, the analysis of one document (which contains macros) would take too much time. Interpreting or emulating a macro would lead to either false positive errors or in macro viruses not detected.
Another type of anti-virus, the integrity checker anti-virus, in some cases, does not work: it only checks documents with extensions DOT[8] or DOC (indeed, some anti-virus producers suggest to their users), but Word documents can reside in others extensions than those two, and the content of the document tends to change often.[4]: 605
So, like the heuristic analysis, this can lead to false positives errors, due to the fact that this type of anti-virus checks the whole document.
The last type of anti-virus seen will be the virus-specific scanner.[4]: 608 It searches the signature of viruses, so, the type of anti-virus is weaker than the previous ones.
Indeed, the viruses detected by virus-specific scanners are just the ones known by the software producers (so, more updates are needed than in other types of scanners). Moreover, this type of anti-virus is weak against morphing viruses (cf.section above). If a macro virus change its content (so, its signature), it cannot be detected any more by the virus-specific scanners, even if it is the same virus doing the same actions. Its signature does not match the one declared in the virus scanner.
Additional to the responsibility of the anti-virus is the user's responsibility: if a potential macro virus is detected, the user can choose what to do with it: ignore it, quarantine it or destroy it, but the last option is the most dangerous.
The anti-virus can activate some destructive macro viruses which destroy some data when they are deleted by the anti-virus.
So, both virus scanners and users are responsible for the security and the integrity of the documents/computer.
Moreover, even if the anti-virus is not optimal in the virus detection, most macro viruses are detected and the progression in virus detection improves but with creation of new macro viruses.
References
[edit]- Michael D. Ernst; Greg J. Badros; David Notkin (December 2002). "An Empirical Analysis of C Preprocessor Use". C Preprocessor, Macros. 28 (12): 1146–1170. doi:10.1109/TSE.2002.1158288.
- Steven E. Ganz; Amr Sabry; Walid Taha (2001). "Macros as multi-stage computations: Type-safe, generative, binding macros in MacroML". Macro Language. 36 (10): 74–85. doi:10.1145/507669.507646.
- Gerard J. Holzmann. "The power of ten - Rules for developing safety critical code" (PDF). safety of macros. p. 4.
- William Clinger; Jonathan Rees (1991). "Macros that work". Proceedings of the 18th ACM SIGPLAN-SIGACT symposium on Principles of programming languages - POPL '91. pp. 155–162. doi:10.1145/99583.99607. ISBN 0897914198. S2CID 5340096.
{{cite book}}
:|work=
ignored (help) - Vesselin Bontchev (1996). "Possible macro virus attacks and how to prevent them". Virus, Macros, Safety of Macros. 15 (7): 595–626. doi:10.1016/S0167-4048(97)88131-X.
Notes
[edit]- ^ Gerard J. Holzmann. "The power of ten - Rules for developing safety critical code" (PDF). safety of macros. p. 4.
- ^ Michael D. Ernst; Greg J. Badros; David Notkin (December 2002). "An Empirical Analysis of C Preprocessor Use". C Preprocessor, Macros. 28 (12): 1146–1170. doi:10.1109/TSE.2002.1158288.
- ^ Vesselin Bontchev. "Macro Virus Identification Problems". macros viruses. Archived from the original on 2012-08-05.
- ^ a b c d e f g h i j Vesselin Bontchev (1996). "Possible macro virus attacks and how to prevent them". Virus, Macros, Safety of Macros. 15 (7): 595. doi:10.1016/S0167-4048(97)88131-X.
- ^ a b c Paul Docherty; Peter Simpson (1999). "Macro attacks: What next after Melissa?". Viruses, Safety of Macros. 18 (5): 391–395. doi:10.1016/S0167-4048(99)80084-4.
- ^ Polymorphics macros
- ^ "Macro Virus Colors". Archived from the original on 2012-11-22. Retrieved 2012-12-15.
- ^ DOT extension