full-disclosure - Microsoft Outlook PST Exposure

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <3F528EE5.1916.AF05065A@localhost>
From: nick at virus-l.demon.co.uk (Nick FitzGerald)
Subject: Microsoft Outlook PST Exposure

"Kaveh Mofidi" <Admin@...ureTarget.Net> warped the ether with:

> Secure Target Network (Security Advisory August 31, 2003) 
> Topic: Microsoft Outlook PST Exposure
> Discovery Date: August 28, 2003
> Link to Original Advisory: http://securetarget.net/advisory.htm
<<snip usual rubbish about Outlook PST files, etc, etc>>

This "vulnerability" is discovered and published on lists such as this 
at least twice a year.

It is not a vulnerability.

Many, many Email and related messaging products behave precisely this 
way.  It's a widely acepted disk-space vs. performance tradeoff in flat-
file databases that, despite records being deleted, the data file grows 
as records are added.  An index is used to keep track of the "active" 
and deleted records.  It is also common that once a given percentage of 
the data filesize, absolute volume, etc is "wasted" holding deleted 
records some form of maintenance routine re-writes the whole data file, 
retaining only the "active" records.

If you have discovered anything it is just that you did not previously 
know how this part of Outlook works.  This has been reported before, as 
it has for Outlook Express.  Several times.

And don't get all steamed up about it -- sure the MS documentation is 
not exactly crystal clear on this and could do better, but MS is 
certainly not the sole developer whose Email client works this way, nor 
did MS invent this approach.  From memory, Eudora and Pegasus Mail, and 
I'm fairly sure The Bat! and at least some versions of the Notes 
clients have all been reported to work thus, and most (if not all) of 
the venerable *nix mail clients do not immediately compact their folder 
files on _every_ message deletion (though doing so on exit from the 
client rather than once some space "wastage" criterion is reached is 
probably a more common default behaviour with such clients).

Regards,

Nick FitzGerald