WhatsApp Isn't Fully Deleting Its 'Deleted' Chats (theverge.com)

Facebook-owned messaging app WhatsApp retains and stores chat logs even after those messages have been deleted, according to iOS researcher Jonathan Zdziarski. The Verge reports: Examining disk images taken from the most recent version of the app, Zdziarski found that the software retains and stores a forensic trace of the chat logs even after the chats have been deleted, creating a potential treasure trove of information for anyone with physical access to the device. The same data could also be recoverable through any remote backup systems in place. In most cases, the data is marked as deleted by the app itself -- but because it has not been overwritten, it is still recoverable through forensic tools. Zdziarski attributed the problem to the SQLite library used in coding the app, which does not overwrite by default. WhatsApp was applauded by many privacy advocates for switching to default end-to-end encryption through the Signal protocol, a process that completed this April. But that system only protects data in transit, preventing carriers and other intermediaries from spying on conversations as they travel across the network.

Comments

Not a SQLite problem

[QuietLagoon]

...Zdziarski attributed the problem to the SQLite library used in coding the app, which does not overwrite by default. ...

That's not the root cause.

The root cause is the programmer who used SQLite and did not know that SQLite did not fully delete, or did know but did not care.

SQLite will only do what it is told to do by the programmer.

Re:Not a SQLite problem

[Anonymous Coward]

...Zdziarski attributed the problem to the SQLite library used in coding the app, which does not overwrite by default. ...

That's not the root cause.

The root cause is the programmer who used SQLite and did not know that SQLite did not fully delete, or did know but did not care.

That's not the root cause. The root cause are the people who taught the programmer, for not teaching the programmer better.

No wait, the root cause is the programmer's parents, for birthing the programmer.

No wait, the root cause is the programmer's grand parents, for birthing the parents who birthed the programmer.

No wait...

Bottom line, what makes your "root cause" more valid than the one that TFS mentioned?

Re:Not a SQLite problem

[Anonymous Coward]

So SQLite need to a secure delete mode.

Re:Not a SQLite problem

[mi]

did not know that SQLite did not fully delete.

One way or the other, it is most unlikely the reason is some deliberate action by WhatsApp or evidence of its collaboration with police.

Interestingly, DBase and Clipper weren't deleting records in DBF-files either — only marking them as deleted... But, hey, every new generation of programmers thinks, those before them were mostly morons and never encountered the "unique" problems they are facing.

Re:Not a SQLite problem

[Anonymous Coward]

...Zdziarski attributed the problem to the SQLite library used in coding the app, which does not overwrite by default. ...

That's not the root cause.

The root cause is the programmer who used SQLite and did not know that SQLite did not fully delete, or did know but did not care.

SQLite will only do what it is told to do by the programmer.

Why, one might think a multi-billion dollar company could afford the cost of getting this right.

Or ... You mean to tell me, Facebook fucked up on privacy?! How ... strange! Isn't it interesting that when a large corporation makes an "error", it's almost always in their favor?

Re:Not a SQLite problem

[QuietLagoon]

...Bottom line, what makes your "root cause" more valid than the one that TFS mentioned?...

If the requirement of the app is to properly and fully delete messages, it is the responsibility of the programmer who implements that requirement to assure the requirement is satisfied. It is not the responsibility of the tool to assure it is being properly used to meet the requirements of the app.

Re:Not a SQLite problem

[QuietLagoon]

It's been a while since I've used SQLite, maybe it does have a secure delete mode, I don't know. But if it doesn't, then it may not be the correct tool for the job.

Re: Not a SQLite problem

[Anonymous Coward]

It makes sense to not really delet data in a database that may need to be rolled back at any time.

Re:Not a SQLite problem

[Alumoi]

If the requirement of the app is to properly and fully delete messages, it is the responsibility of the programmer who implements that requirement to assure the requirement is satisfied.

Ergo, the requirement was to keep the messages while telling the user they were deleted. Who would have thought?

Re:Not a SQLite problem

[DRichardHipp]

In SQLite, you can do "PRAGMA secure_delete=ON;" and it will subsequently overwrite all deleted information with zeros. This is turned off by default because it does more disk I/O. Alternatively, one can run "VACUUM" at any time to ensure that all deleted content has been purged from the database file.

Re:Not a SQLite problem

[BarbaraHudson]

Deleting record contents in dBASE was easy - just run a batch process every day that looks for any records with the deletion mark set and overwriting them. Or you could code your programs to overwrite the data before marking it as deleted. Records that were marked as deleted would eventually be overwritten anyway, but why depend on "eventually"? (In other words, it's the programmer's fault for not knowing the limitations of the software).

Or you could just issue the PACK command, but raw disk reads will still show the data on the drive until it's overwritten.

Clipper was the same thing.

In both cases, it's in the accompanying manuals. Problem is, so many people just pirated the programs so they never read the manuals.

Re:Not a SQLite problem

[QuietLagoon]

thanks.

Re:Not a SQLite problem

[allo]

And telling "SQLite does not really delete" is like telling "Your filesystem does not really delete". So what? If you want secure deletion, use secure deletion. If you want to kill sqlite, use the "delete app data" button and import a backup (Whatsapp, not Titaniumbackup) afterwards.

Re: Not a SQLite problem

[Anonymous Coward]

I would say it has more to do with SD wear leveling. Overwrite what you want... there is minimal chance that you are going to hit the same cells on the card.

Re:Not a SQLite problem

[dgatwood]

In SQLite, you can do "PRAGMA secure_delete=ON;" and it will subsequently overwrite all deleted information with zeros. This is turned off by default because it does more disk I/O. Alternatively, one can run "VACUUM" at any time to ensure that all deleted content has been purged from the database file.

The concern goes deeper than just disk I/O. On flash, there's a limited number of writes per flash erasure block, and using it in a mode that continuously overwrites everything you delete significantly increases the rate at which you burn through those write cycles. The OS is likely to coalesce a lot of those writes if they happen close enough together, but you're still abusing the hardware pretty badly by doing that.

The right approach is to come up with a reasonable policy for retention, e.g. "Guaranteed to not retain data more than n hours" and then vacuum the database every n hours, or when the OS tells you that your app is about to get terminated (assuming you can safely do it in such a short time), or when your app gets backgrounded (if you can't). Either way, vacuuming constantly is bad for the hardware, and never vacuuming is bad for security. The key is to find the right balance, and that pretty much requires your programmers to know that this issue exists, which most SQLite users no doubt do not.

And a couple of aspects of the design of iOS contribute to this problem negatively. If this were on a real computer:

• You'd probably have a MySQL or PostgreSQL instance holding that data, and it would scrub periodically in the background. You can't do that you iOS, because you can't have a background daemon running when your app isn't running, so everybody ends up using SQLite, which is just barely enough of a database to be usable.
• You wouldn't have the OS killing your app randomly while it is backgrounded, making it impractical to guarantee that you'll get n seconds to scrub every so many hours.

I'd love to see iOS add a centralized SQL database running on it at all times, with periodic scrubbing, with the ability to selectively share tables across apps, etc.

looking up carbon based life form on alphabet.com

[Anonymous Coward]

we're overdosing on the stuff? dark matters for sure.. cease fire stand down,, truth+mercy=justice,, spirit of creation supplies more than enough of all we need with no personal gain motive etc... in the moms we trust,, hand in hand we stand

Normal

[darkain]

This is pretty much normal of almost all modern systems, not sure why a single application is being targeted here? Look at ANY Copy-On-Write based file system, and you'll see this "doesn't erase" same practice. Of course the same will hold true for a Copy-On-Write database as well.

VACUUM

[Anonymous Coward]

TFA notes early on that by default the sqlite database does perform a vacuum operation, leading to this problem. At the end it lists a whole bunch of possible ways Whatsapp can fix this problem. While completely leaving out the most obvious fix which is to use sqlite's built in VACUUM function manually.

Fail is another 4 letter word

[BoRegardless]

How can a company declare a product "secure" when obviously no security audit was done?

If WhatsApp merely stated that in transit is encrypted, but data on your phone is open to discovery, even if deleted, at least they would have been honest.

Re:Fail is another 4 letter word

[Anonymous Coward]

How can a company declare a product "secure" when obviously no security audit was done?

"Secure" is the IT equivalent of "Organic".

Re:Fail is another 4 letter word

[The-Ixian]

Well, yeah.

"Secure" is a relative term. Obviously, when communicating there is no such thing as 100% security.

Anyway, given the lengths to which WhatsApp has gone to implement the Signal protocol, it is not hard to imagine that this small loophole will be closed soon enough.

Still, whether the hole is closed or not, loss of physical access to a communication device should always be considered a breach of your security. You have to assume if someone has physical access to your device that the information contained within it is compromised.

Re:Fail is another 4 letter word

[Anonymous Coward]

This is simple. The communication is secure, the device was simply assumed to be in possession of the owner.

Security is about defending against threats, if malefactor taking possession of the device isn't in your threat model, it would be easy to overlook this issue.

Re:Fail is another 4 letter word

[Threni]

It's end to end encryption, but at the ends it's not encrypted. That's why you use full disk encryption.

Re:Fail is another 4 letter word

[Anonymous Coward]

Their parent company is Facebook, do really believe they would be honest?! If they said the sky is blue, I'd still look up to check.

Re: Fail is another 4 letter word

[Anonymous Coward]

You mean *All Natural*, organic actually does mean something, if certified.

omg can you imagine

[Anonymous Coward]

if Facebook doesn't "fully" delete its chats too? omg!!

captcha: panicked

Working as designed

[Anonymous Coward]

If you are counting on a app or service to really "delete" you are going to be suprised.

Re:looking up carbon based life form on alphabet.c

[Anonymous Coward]

I'll have what he's having.

Alternate Headline

[Tyrannosaur]

A better headline would be "WhatsApp Isn't Securely Deleting Its 'Deleted' Chats"

Most file systems don't overwrite deleted data until the space is needed again. This is expected behavior.

Of course, this is a flaw that should be fixed- especially that any backups would be able to see everything- but this doesn't look to be a "backdoor" or anything nefarious in WhatsApp.

Re:Alternate Headline

[sexconker]

What's worse is that with flash-based storage, you can't ever be guaranteed that you've overwritten an individual file even if the OS thinks it has overwritten it 100 times with random data.

SSDs and other flash-based storage have wear leveling and over-provisioning which result in your writes not going to any guaranteed physical place.
The only ways to securely overwrite a file on a flash-based device are to:

1) Issue the ATA Secure Erase command and hope the drive actually does its job.
2) Use a tool provided by the manufacturer that issues custom commands to the drive that achieve a similar effect (again, hope that it actually does so).
3) Fill up the drive with random data for years until it's dead. Many drives will enter a read-only state. Others will outright fail. You still have to hope that no copy is left on a physical flash chip in the drive.
4) Physically destroy the drive.

In all cases you lose all the data.

With HDDs you could access individual sectors and zap em as appropriate. With SSDs that's not the case. Everything is logically mapped by a controller and you have to trust it to do a secure erase properly - either resetting the encryption key or filling every block (even the ones used for over-provisioning) with 0s.

Re:Alternate Headline

[allo]

Your first problem is your journalling filesystem. The SSD will at least not give you the content of the deleted sectors without tricks. A disk image of your journalling filesystem will.

Re:Alternate Headline

[sexconker]

The SSD operates below the filesystem. It doesn't matter what filesystem you use. The SSD decides where to put data and where to say data has been put. They won't match up.

Re:Alternate Headline

[lgw]

His point was that there's no way through the normal filesystem interface to recover deleted data on an SSD - you'd have to pull the chips and write your own firmware to explore them. With a journaling filesystem you may be able to "undelete" the file without nearly so much effort. And obviously if you have backups of any kind, that's even easier. Worrying about the SSD seems pretty far down the list.

Re:Alternate Headline

[unrtst]

SSDs frequently encrypt everything on the drive. If you want to ensure everything is gone, destroy the key. Granted, if someone can restore the key, they can decrypt everything, but that's the tradeoff they took.

I suspect the same though was had for WhatsApp's use of SQLite. The messages (I assume) are encrypted at rest. So, an unlinked DB record (deleted but not zero'd out) is just a random binary blob that's only useful if you have the encryption key.

Even if WhatsApp DID zero out the SQLite record, if it's running on a modern smartphone, then the underlying storage probably didn't overwrite the raw data either, and zeros wouldn't actually get written anywhere (SSD's use a fake allocation for all zeros).

Essentially, while things could be better, this isn't *that* big a deal.

Re:Alternate Headline

[caitriona81]

Not only are the established methods for secure erasure ineffective, but they also eat up valuable write cycles on flash chips for no tangible benefit - every write to a flash memory device is in effect a small amount of damage to the device, which when taken cumulatively over a long period of time, will eventually lead to the catastrophic failure of that device.

Worse yet is no ordinary software forensic toolset can even see that this data exists - the device consistently maps even the lowest level APIs around the hidden data - direct, physical methods of reading the data off the chips, or discovery of secret manufacturer APs that may or may not exist in any given product are the only chance to see it - the operating system is oblivious in every case, so there's no way anyone but the manufacturer itself, or a destructive examination inf a forensic lab can tell for sure.

With all that said, with extremely rare exceptions i can count on the fingers of one hand like gpg, the only software packages that even attempts to do secure deletion, in any environment, are standalone secure deletion utilities. The assumption should always be that an application does not provide secure deletion, or even secure storage of data at rest, because this is almost universally true, even in supposedly security conscious applications. If it doesn't make any specific claims about secure erasure, it most certainly doesn't do it. Insecure storage, and cleartext data at rest are the norm, even in 2016, even in supposedly "secure" applications.

Using full disk encryption, with a robust passphrase lock, or a robust passphrase lock coupled with biometrics should be the default for anyone carrying sensitive information on a mobile device.

Re:Alternate Headline

[sexconker]

You don't need to pull the chips, though that's not very hard.

You can send a national security letter to Samsung.
You can hack your own firmware together and flash it to the drive and have the drive dump out the contents of every flash chip.

For backups, everything should be stored encrypted (with a key you control).

For generic filesystem issues, use a better filesystem? Or at least one that provides a way to truly delete/overwrite space marked as free?

Re:Alternate Headline

[sexconker]

A lot of SSDs even get that part wrong, storing the key in an easy-to-get area, not really deleting it and creating a new one, etc.
But even when it works, you can't delete "MySecretFile.txt" without also deleting everything else on the drive.

Re:Alternate Headline

[Kjella]

With HDDs you could access individual sectors and zap em as appropriate. With SSDs that's not the case. Everything is logically mapped by a controller and you have to trust it to do a secure erase properly - either resetting the encryption key or filling every block (even the ones used for over-provisioning) with 0s.

It's been a long, long time since you could do that. All modern HDDs do sector remapping behind the scenes, whatever written to a sector the disk later identifies as wonky and remaps is untouchable. Only secure erase will overwrite every sector, it predates SSDs by many years.

Re:Alternate Headline

[allo]

Strange, somehow it still sounds easier to dump the blockdevice, search for "From: Some Name" string inside the Dump and then cut a big block around it and recover the deleted e-mail instead of sending NSLs to Samsung to create a new firmware.

Yes, deleted files are (sometimes) recoverable

[T.E.D.]

In most cases, the data is marked as deleted by the app itself -- but because it has not been overwritten, it is still recoverable through forensic tools.

For the record, this is exactly what happens when you "delete" any file. The file system just goes to its little index of disk locations in use, and marks the ones the file's data is sitting in as available. Quick and easy. The data is all still there until the filesystem happens to give those locations away to a new file some day. There's nothing at all special about WhatsApp here. This is just how filesystems work.

Security professionals (eg: when I was working COMSEC jobs for the DoD) know to "zeroize" old data you really want to be non-recoverable. When last I checked, that's a matter of writing patterns of 1's and 0's repeatedly to the disk enough that the old data patterns are no longer recoverable. But typical OS's don't have that as a native operation, and it would be fairly unreasonable (not to mention dangerous) to expect a simple social media phone app to be jumping around the OS to do things like that itself.

Re:Yes, deleted files are (sometimes) recoverable

[Lumpy]

writing once is enough. It's an urban myth that you have to do it more than once to obliterate the data. Manybe with old 10megabyte RLL and MFM drives you could easily recover information as the head was miles wide and the slop from the track move was insane enough that you cna easily see it. bot for the past 10 years a single wipe of zeros will make it impossible for the worlds best hackers to read the data on a modern hard drive.

Re:Yes, deleted files are (sometimes) recoverable

[Anonymous Coward]

> ...that's a matter of writing patterns of 1's and 0's repeatedly to the disk enough that the old data patterns are no longer recoverable.

For spinning rust that works just fine, most of the time. Flash is another story entirely. It's likely that your overwrites will get put into _other_ free cells, and the flash controller will mark the cells you're trying to overwrite as free, rather than overwriting them. Depending on your usage patterns, they might _never_ get overwritten. Aaaaaaand we're back to the problem we were trying to solve... just one layer lower. :(

Re:Yes, deleted files are (sometimes) recoverable

[dgatwood]

For spinning rust that works just fine, most of the time. Flash is another story entirely. It's likely that your overwrites will get put into _other_ free cells, and the flash controller will mark the cells you're trying to overwrite as free, rather than overwriting them. Depending on your usage patterns, they might _never_ get overwritten. Aaaaaaand we're back to the problem we were trying to solve... just one layer lower. :(

There actually is a way, but it involves creating a file that's as big as the remaining space on the volume, to ensure that there are no flash pages that don't get rewritten. And even then, that doesn't quite guarantee that it will get overwritten because the flash page you're trying to overwrite could get spared and replaced with a free page. Obviously if you do that enough times, it will eventually get overwritten, but you'll also drastically shorten the life of the flash disk.

A better solution, of course, is to have a flash controller that supports TRIM properly and guarantees that overwritten pages get zeroed in a timely manner. If you have that, then overwriting the data once is sufficient, because the data will eventually get zeroed. And frankly, there's no good reason for a flash controller to not aggressively erase pages that are no longer tied to the filesystem (the old version of the data), because they are unlikely to ever be used again.

Flash!

[sanf780]

So the solution is to hammer the non volatile storage with over 38 writes so that nobody can recover your joke of the day, am I wrong?
At some stage you need to balance convenience and security.

Re:Flash!

[Anonymous Coward]

That depends. If WhatsApp advertises itself as being a convenient social media product, then all is good. If What'sApp advertises itself as being a product with superior privacy, then doing a basic overwrite (or two, or three... probably not the "38" you exaggerate) would be appropriate.

So what is WhatsApp?

Re:Flash!

[sanf780]

I had a look at WhatsApp website. Its main selling point is that there is no SMS surchages. It does not claim any other security measure other than ciphering the messages in any one to one conversation, for example, when you exchange some of your most personal moments aka underage sexting. These messages are not stored in their servers - that would be bad for their reputation. It does not claim the messages are encrypted on your phone, and that neither RAM or flash is being overwritten.

Talking about other things, overwritting 38 times the same hard disk over and over is something that a notorious political party does when recycling old computers in the country where I am. That the person in charge of that computer was being investigated by the authorities had nothing to do with the recycling policy.

Re:Flash!

[jargonburn]

I think GP was perhaps alluding the Gutmann method (35-pass) of sanitizing data on a hard-drive. Which method has been obsolete since the late 90s, as it was specifically designed to wipe HDDs using MFM/RLL (how magnetic signals detected on the hard-drive were interpreted). With newer magnetic media, one pass is honestly "good enough". Three passes using a well-known standard can afford you better peace of mind while also allowing you to comply with most official "secure wipe" requirements.

Unless GP specifically meant Flash/chip-based storage, in which case, your best bet may be a drive that destroys its media if the drive's enclosure is compromised.

unavailability of god the mother raising questions

[Anonymous Coward]

where is she? victim of pr firm blacklisting perhaps? pretense about stuff that really matters is no longer viable? wmd starvation remains as #1 killer of us world wide... no wonder creation is in a near tailspin? free the (also) innocent stem cells....

More LUDDITE lies!

[Anonymous Coward]

ONLY apps can app apps, NOT LUDDITE software like LUDDITE SQLite!

Apps!

SLASHDOT ADVERTIZES MALWARE

[Anonymous Coward]

Sponsored ads by Traboola
"Pretty Basket Shop" (whatever the fuck that is)
https://trc.taboola.com/slashd...
took me to your average run-of-the-mill malware page, complete with multiple popups preventing me from closing the tab, and annoying computer voice telling me in broken english that I am infected with a virus.
SLASHDOT IS DEAD.

In other news

[Nunya666]

It's being rumored that the Sun is hot.

Deleted? Yeah right.

[antdude]

If it is on the server, I am always going to assume that they keep them on backups and stuff even if I deleted them. :(

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:Nothing on FACEBOOK is deleted either

[Anonymous Coward]

-1? why not -100 so you know it is for sure true.