Open office security hole

Hi all.
I found out about a security hole in Openoffice text file. When you save a picture in a *.odt document and encrypt it, it is secured with a 256AES encryption. But when you open the file again, it decrypts its content and saves it in the temporary folder, so that you can view it. Then when you close the document again, document itself is secured, but the decrypted content in the temp folder is not wiped out (just normal deletion) and it can easily be restored with recovery software (Recuva). So any one who has a 5 minutes of spare time, can view the content of odt files if they were opened once. I tested this myself.

 

You might want to send off an email to the authors.

 

Alternatively, you could mention in this forum: http://user.services.openoffice.org/en/forum/index.php

 

the machine where the files are being decrypted should be secured/safe/trusted. If somebody has computer access and it shouldn't the least problem is being able to access temp folders

 

Point is not is the machine secure or not. Even if the machine is "super secure" and you would trust the owner your life and you were the one that set up all the security on that machine. Point is that encrypted document leaves its content unencrypted and then just deletes it so that recovery software can easily restore it. The easiest way to test this is to use a picture in the *.odt file; OO will then extract it as some *.tmp file in the temp folder, but the content can be viewed with recovery apps.
And YES , picture was wiped out after the odt was created and YES free space was overwritten as well, but when the file is opened and closed again, then...

 

No, that machine is secure is the point or else the so called recovery software would not be running. Or the file would have been read within a sandbox and wiped etc etc. The file has to be decrypted in order for us to read it and it is encrypted so that some 3rd parties can not access it if intercepted. If 3rd parties have already infiltrated and have access to the machine then .....

 

Then this would make all encryption useful only for transport/sending, unless the disk is wiped out every time any file is decrypted. When decryption is made, the content should be in the memory or wiped out at the end if it is on the drive.
If all would relay only on the safe machine, then rather than all the security apps we are using, we should be carrying our laptops around or live cd. My concept of security is: protecting content, not the place

p.s. I understand that basic screen logger could record the file after it is opened, and that alot of things can happen when the file is decrypted for viewing, but this problem (the first one appears when the file is closed back.

 

when it is decrypted then it is vulnerable and it should be protected but that is not the job of the software that encrypted it. not unless it is marketed as such

 

There are many ways unencrypted data can leak and remain on a system. Full disk encryption is an obvious answer for this problem. In this case however one should note that the very software that's used for the encryption is the cause of the leak. Poor design and more specifically a bug, especially since a solution is so easy?
On the other hand one could argue the OOo encryption is only meant and designed as a measure to secure a document when it's sent over the insecure networks and it's not in it's scope to protect the data once it's been stored and decrypted on a system. Another argument against implementing a more secure temp file is, it would give a false sense of security. IMO that's more dangerous than no security.
In the end it's entirely up to the devs to make the decision. What I'd welcome in any case would be that the communication on these matters is improved, for example mentioning it in their wiki.

 

yes there are a lot of things that can happen to data when they are decrypted, and we all understand that data has to be somewhere decrypted so that we can view it, but when some app encrypts data, (and there are no traces of the original data or any modified data left because they are overwritten) the least measure of iq should be, that app would not leave so called "protected" data all around.
Imagine if such a concept of security would exist in the "physical" world.

 

as suggested earlier in the thread did you contact OO regarding your thoughts? They seem to be working on enhancing that function
http://wiki.services.openoffice.org/wiki/Security/Encryption

 

yup, posted it on their support thingy. Well this isn't so much of a risk to me, as posted in another post, i got nothing on my pc worth protecting, no passwords, no files, all i do is firefox-ing an notepad-ing. But i do take interest in security and privacy.
tnx

 

This is an issue with all encrypt in place software -- not just OpenOffice. If you aren't using full disk encryption, chances are the decrypted files are on the filesystem. I suppose the software could do a "secure-delete" of the decrypted file after it is closed, but that is impractical in many cases because the user may not want it deleted when it's closed.

Bottom line: it is the user's responsibility to securely erase sensitive files. If you don't like that hassle, use TrueCrypt or some other FDE solution.

 

And why would they want that?

OOo currently deletes the file anyway. It's obviously practical, so your point is more or less moot.

 

So, OOo securely erases files? That is, it overwrites them?

 

I'm not quite sure what hand you're trying to play here.

Are you saying its practical to delete the files from the temp folder, but not to securely erase them?

 

Merely deleting the file does not get rid of it. You must securely erase it (i.e. overwrite it with random data or zeros). Does OOo do this?

 

According to the OP, no, it doesn't. That's why this loophole exists.

Now, your point is... ?

 

No, not with software that only decrypts to RAM.

True, through page file for example or at least "hints" like through MRU, maybe also crash recovery. But that's not the point of this thread, see below.

We are only talking about a temporary file that's automatically created without the user's consent or knowledge.
It's entirely practical and warranted in every possible case to do a secure erase here. The ONLY drawback is closing an encrypted document is a bit slower.
It's the user's responsibility to delete the "original files" used for an encrypted document for example, that's pretty obvious (however next to impossible on a journaled FS with scheduled defragmentation). However the creation of a needlessly unencrypted and unsecured temp file is entirely non-obvious and therefore I'd argue, not the user's responsibility. FDE works but it's bit of a sledgehammer solution.

 

It's not impossible depending on the filesystem and how it's mounted. For instance, on ext3/4 if the filesystem is mounted data=ordered, such overwrite in place operations work well.

I suppose this all depends on what security the encryption built into OOo is intended to achieve. It seems like it is more of a solution for e-mailing attachments securely. If this is the case, the temp file makes no difference.

In any case, as you admitted, unencrypted files are probably floating around somewhere in swap space anyway, regardless of whether there is a temp file or not. The only solution, other than doing constant wiping of free space, is FDE. So, I don't think it's a sledgehammer solution at all.

 

Well i disabled page-file, so there is nothing in there. I agree, if Oo can place decrypted data on the drive (i do not a pose to that, although it might be done better) it can take the effort to wipe them out when closing. It doesn't have to be gutmann method, one random pass would do the trick. Because now we are at the point where it is "advertised" that if your file is protected with AES it would take 1000000 years to break the code, but it takes me 1h to find the data with deep recovery scan unless if i wipe the freespace (but that would need to be repeated every time when i use my CV)

 

If you read my first post again you'll see with the "false sense of security" I had exactly these kinds of side channel issues in mind and I also already mentioned that it "depends" on what's the scope of the encryption: securing it while being sent to others or securing it while stored locally.

However the problem here is something else: Someone had to discover this issue using recovery software. The problem is, this isn't mentioned anywhere to my knowledge, like on its wiki or help files.
One can work around side attacks like disabling or erasing swap/pagefile, disabling fragmentation or using -non default- mount options you mentioned (note my "next" to impossible). Savvy users know these pitfalls but who knew open office was writing temp files in plain text even when using encryption? I don't care how this is resolved. But as the case is now, something needs to be done by the OOo devs. Either make it clear to the user that this issue exists and what's the scope and limitation of their encryption or fix it. Making the blanket recommendation that everyone should use FDE because it "wouldn't matter anyway" is what I called the sledgehammer.

 

I don't disagree that perhaps the OOo devs could make this more clear. But, I don't think there's much they can do, other than giving a warning, because if you're not using FDE, the unencrypted files (no matter if its from OOo or not) will most probably be floating around somewhere on the drive anyway. It's not really the problem of encryption software if the file is stored in swap/page file, etc. I agree that this OOo temp file should be documented, or at least wiped by OOo after decryption is complete. But even wiping it wont guarantee its destruction, depending on what filesystem is being used with what options.

I suppose my point is you just can't be sure (due to the large size of modern hard disks, the way most filesystems journal, and the unpredictable way swap/page files work) if an unencrypted file is still on the disk somewhere or not. The only options are wiping free space or FDE. I, personally, find FDE more convenient.

 

got an answer from oo support:

"It is a question of luck whether the disk-part related to the temporary file is
overwritten after the file has been deleted. The office does not overwrite the
temporary file space explicitly, although it could be done. The problem is that
it might affect performance, although it is probably the only way to solve it in
3.3."