Excel workbook protection and sheet protection are commonly used as if they provide file security. It turns out that these mechanisms do NOT provide file security, nor were they ever intended to do so. Section 18.2.29 of ECMA-376-1:2016, the latest version of the standard governing Office Open XML, says the following:
Applications might use workbook protection to prevent anyone from accidentally changing, moving, or deleting important data. This protection can be ignored by applications which choose not to support this optional protection mechanism.
The same section contains an additional note:
Worksheet or workbook element protection should not be confused with file security. It is not meant to make your workbook safe from unintentional modification, and cannot protect it from malicious modification.
Both sheet protection and workbook protection may be removed without the protection password in four basic steps:
- Unzip the .xlsx or .xlsm file so that its contents may be modified in the following steps. Excel workbook files are actually ZIP files with a different file name extension.
- Remove the <workbookProtection ... /> XML tag from the xl\workbook.xml file.
- Remove the <sheetProtection ... /> XML tag from any .xml file in the xl\worksheets\ directory.
- Zip the modified Excel workbook file contents, using the .xlsx or .xlsm filename extension for the resulting ZIP file.
I have published a detailed PDF guide for accomplishing these steps using only File Explorer and Notepad on Windows.
Is anyone else surprised by how easy it is to bypass these protections?
(Score: 4, Insightful) by Anonymous Coward on Monday July 08 2019, @04:12AM (7 children)
Nobody should be. As much as I like to gloat about Micro$oft's fuckups, this is taking a format that wasn't designed for security, just for protection against accidental modification, and removing that protection. Sort of like sticking over the write protect notch in a cassette.
(Score: -1, Troll) by Anonymous Coward on Monday July 08 2019, @04:15AM
A non-story, indeed.
WTF, S/N, slow news day or what?
(Score: 2, Insightful) by Anonymous Coward on Monday July 08 2019, @04:19AM (1 child)
Perhaps what is surprising is the extent to which people rely on these mechanisms for file security and don't know how easy they are to bypass.
(Score: 0) by Anonymous Coward on Monday July 08 2019, @05:01AM
Or to what extent formats aren't loaded down with DRM yet.
(Score: 0) by Anonymous Coward on Monday July 08 2019, @04:54AM (3 children)
Yeah, not surprised at all. If you actually try to use the protections on the versions of multiple office suites I have on hand, all warned me not to mistake protections for actual security.
But then again, I'm also not surprised since I have worked with the ECMA specification and none of the protections specified for OPC (open packaging conventions) files under standard ECMA-376 part 2 and ISO/IEC 29500-2 are supposed to be relied on for sensitive protections, except for if a digital signature fails (although that too could be ignored). Hell, if you read the actual specification or open up the xml document (after unzipping, of course) you'll see that the protection password is sitting there in plain text! Instead, you need to use the CFB (Compound File Binary) format for your files to ensure that sensitive protections are implemented and not ignored (with the R.O. flag set).
(Score: 0) by Anonymous Coward on Monday July 08 2019, @05:03AM (2 children)
It would be nice if Excel did this.
In the file that I looked at, the protection password was stored as a salted SHA-512 hash.
(Score: 0) by Anonymous Coward on Monday July 08 2019, @06:04AM (1 child)
365, 2019, and my personal copy of 2016 all warned for me, but I could see if I can get my hands on older/other ones.
Curious what version you used to save said file. I double checked the specifications, and I was looking at an older version (plus there are various differences between older versions of the ISO/IEC versions and the ECMA ones). Originally, it was encoded plain text, then they came up with their own hash (now called the Legacy Password Hash) to hash the password (after truncating it), then they allowed some less secure hash algorithms, then they added much stronger ones and allowed for repeated iterations of hashes. But, interestingly most software uses the "transitional" schema or an older revision which does allow for the LPH or plain text (which I've run into the most, but that might be sample bias the more I think about it).
(Score: 0) by Anonymous Coward on Monday July 08 2019, @07:06AM
Home & Student 2016, Version 1906.
(Score: 2) by progo on Monday July 08 2019, @05:20AM (2 children)
This just in! If you can read it, you can edit it.
(Score: 0) by Anonymous Coward on Monday July 08 2019, @08:28AM (1 child)
Amazing. Its in the spec. and people claiming to be rational, even intelligent, walk around with delusions -- the popping of which they find oh so worthwhile to share! ... now where's that xkcd cartoon ... just one in the 10,000 who learned that something today.
it'll be cool to watch how long it takes for the poster to start calling hirself a security-researcher.
(Score: 0) by Anonymous Coward on Monday July 08 2019, @02:19PM
Same anon as the poster here.
I've never turned on these protections in a file myself but needed to remove them from a file someone else sent me. What boggled my mind is that people rely on these mechanisms for security when the spec says not to. My coworkers were surprised by it, so I guess the lack of awareness of what the spec says is pretty common.
(Score: 3, Interesting) by EJ on Monday July 08 2019, @06:37AM (3 children)
I never knew they were just zip files with the extension changed. I doubt I would ever have been curious enough to check.
Funny the random new things you learn each day.
(Score: -1, Troll) by Anonymous Coward on Monday July 08 2019, @12:10PM (2 children)
Sad.....
Have you no curiosity?
(Score: 3, Funny) by toddestan on Tuesday July 09 2019, @02:14AM (1 child)
"So, what do you like to do for fun?"
"I like running unzip on random files on my filesystem to see what happens..."
(Score: 0) by Anonymous Coward on Tuesday July 09 2019, @09:34AM
Actually, I figured it out when I opened the file up in a hex editor. The first few characters can sometimes give away a file type. I had opened zip files in the past that way, and when I opened up a Excel or Word document, I found that out. Zipping it back up and keeping it functional can sometimes be a challenge. I'm not sure exactly what settings it uses.
(Score: 1, Funny) by Anonymous Coward on Monday July 08 2019, @08:25AM
*snicker*
(Score: 3, Insightful) by Veyrdite on Monday July 08 2019, @09:58AM (11 children)
If you can see some information on your computer screen then you already have a full copy of it, any restrictions to editing are fake or misleading. It's just like having a paper printout of the document in your hands (your computer) and being told that you can't draw on it, it's locked.
Summary of options:
(Score: 1) by shrewdsheep on Monday July 08 2019, @10:06AM
Unless there is a full implementation of trusted boot, signed applications and DRM (including the screen). I am convinced that such a future is encroaching on us and will not be avoidable entirely even under Linux unless you do not have to interact with the real world.
Then I will hack my display to tap the digital output, I hear you say. Yes, there will be a cat and mouse game to work around DRM but it can be costly. The most efficient way for circumvention will probably be going analogue and then AD (using the almighty AIs to get rid of the artifacts).
(Score: 3, Insightful) by Runaway1956 on Monday July 08 2019, @10:17AM (4 children)
Isn't there an option 4?
4. Use FUD to convince people that they can't edit a file.
My employer, for instance, would call unlocking an .xml file "hacking", and fire the guilty party. Which isn't really much different from the physical paper copy you mentioned. "Oh, you can't make marks on that!"
Your reference to a paper printout reminds me of the various forms I've used over the decades. Warnings like "Do not fold, spindle, or mutilate." "Make no marks in this area." Or, "Make no marks outside of this area." Tests answer sheets that consisted of 4 columns of little circles, where you darkened one of the circles with a #2 pencil. And, people followed along, obeying whatever instructions were printed.
That doesn't even touch on all the many forms with "Press hard, you are making xx copies." Anywhere from three to 12 copies, with each copy destined to fill some other person's in-basket.
And, FUD always guaranteed that all those copies got to their proper destinations.
(Score: 2) by sgleysti on Monday July 08 2019, @12:26PM (2 children)
As a Quaker, I abstain from filling out forms in triplicate (or higher).
(Score: 0) by Anonymous Coward on Monday July 08 2019, @01:03PM (1 child)
Q. for the Quaker -- do you ever sit around in a small group and quake (bodies shaking or shuddering)? Couldn't find a quick reference, but I seem to remember this was part of the history of the sect.
(Score: 2) by sgleysti on Monday July 08 2019, @02:21PM
Not really a Quaker, just making a bad joke. It could be something like you suggest; see https://www.etymonline.com/word/quaker [etymonline.com]
(Score: 2) by EJ on Tuesday July 09 2019, @02:07AM
Your examples are more like handicapped parking signs. It's not FUD. It's not telling you that you cannot park there. It's telling you that you're not ALLOWED to park there.
(Score: 0) by Anonymous Coward on Monday July 08 2019, @03:05PM (1 child)
Another possible variant of this is that you could cryptographically sign the data, so it's "locked" in the sense that modifications are detectable. Of course, then you need to worry about the source of truth for what key should be signing the file. And you need to worry about what happens if the edit includes just deleting the signature entirely (i.e. "valid signature" and "no signature" are easy to confuse when not all files are signed).
(Score: 0) by Anonymous Coward on Monday July 08 2019, @06:41PM
Not the GP, but that is technically only making it "harder" to edit. Beside the obvious of just retyping it into a new version, you could, theoretically, tamper with the message and still have a good signature. Different algorithms have different sensitivity to this, of course, but it is a distinct possibility, even more so if you don't use an iterative hash or something like MD5 or SHA-512, which are vulnerable to length extension attacks.
(Score: 0) by Anonymous Coward on Monday July 08 2019, @08:24PM
That's why digital signatures exist. Here is the info, and here's the cryptographic proof that its the info I intended to give you, i.e. that nobody changed it.
Of course it imposes a burden on the consumer to verify that signature. A burden apparently so onerous that nobody ever does it.
(Score: 1, Interesting) by Anonymous Coward on Monday July 08 2019, @11:30PM
Absolutely agree .. see also: http://thruglassxfer.com/ [thruglassxfer.com]
(Score: 2) by EJ on Tuesday July 09 2019, @02:12AM
There actually is a way to do this:
4. Make the content available only via an online file, like Google Docs. Sure, you can make a copy of that file and edit it all you want, but everyone who goes to access the file will still only ever see the original.