poifs: Orphan VBA directory entry when removed

[Maxime GUERREIRO <ma...@me.com>]

Hello there,
I'm trying to remove a directory structure from a Composite Document
File V2 Document file,
and my code is working in every cases I could test except one.

Here it is: https://gist.github.com/mguerreiro/7023cab737917e936ac40857cdc12035
sampleCall is the call I'm using.

My issue is that when trying to nuke "Macros", I have a stale
directory entry named "VBA".
I can't find it using Apache POI's API: it doesn't seem to detect
orphans (why would it, after all?), so I can't remove them manually
either.

The sample file I'm using:
https://plik.root.gg/file/C1eIAG4bBN2Nteio/iakCcsP6tiFn22mG/bill44955.doc
Beware, this is a malware. Auth.: user "plik" password "infected"

To see the orphan entry, I use oletools
(https://www.decalage.info/python/oletools, down at the moment):
Results before and after are in the gist.

I've tried to call "renameTo" instead of "remove", but it causes an
infinite loop in oletools.
What I thing is causing this issue: somehow the references are not
updated, and for some reasons a stale pointer is left.

Would you, by chance, have any idea on how I could prevent this from happening?
Is this a bug on your side?

PS/ All I want is the "VBA" directory to disappear, should I rename or
remove it.

Best regards,
Maxime G.

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@poi.apache.org
For additional commands, e-mail: user-help@poi.apache.org

Re: poifs: Orphan VBA directory entry when removed

[Nick Burch <ap...@gagravarr.org>]

On Mon, 5 Dec 2016, Maxime GUERREIRO wrote:
> I'm trying to remove a directory structure from a Composite Document
> File V2 Document file,
> and my code is working in every cases I could test except one.
>
> Here it is: https://gist.github.com/mguerreiro/7023cab737917e936ac40857cdc12035
> sampleCall is the call I'm using.
>
> My issue is that when trying to nuke "Macros", I have a stale
> directory entry named "VBA".
> I can't find it using Apache POI's API: it doesn't seem to detect
> orphans (why would it, after all?), so I can't remove them manually
> either.

I've tried writing a unit test, based on your code, but I can't reproduce 
the issue. See RecursiveDelete() of TestNPOIFSFileSystem

The only thing I will say - NPOIFSFileSystem will only ever extend files, 
never shrink them. It doesn't zero-out removed bits either, just zaps the 
references.

We've talked about adding a "defrag" mode to it, but not for a while. The 
only way to fully get the space back from deleted entries / un-used blocks 
is to copy (EntryUtils helps) from the open NPOIFS into a brand new one, 
then save that. If you want to fully zap something nasty, you probably 
want to take that route.

Nick

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@poi.apache.org
For additional commands, e-mail: user-help@poi.apache.org