Dumb bug of the week: Outlook staples your encrypted emails to, er, plaintext copies when sending messages Attention anyone using Microsoft Outlook to encrypt emails. Researchers at security outfit SEC Consult have found a bug in Redmond's software that causes encrypted messages to be sent out with their unencrypted versions attached. You read that right: if you can intercept a network connection transferring an encrypted email, …
This post has been deleted by its author
But even in Linux/Opensource I've seen things labelled as "working as intended" and felt the need to hit a hard object forcefully in rage.
(Personally I don't care who/why/what if the software is doing something obviously wrong/broken or dumb, even if it's third party problems, then don't ask it to do it... I know I should not run into the road, even if a the driver may be at fault, I'll still avoid doing it, and not label my activity as "working as intended" ;) ).
None taken. In fact I'm one of the most vocal opponents of the (albeit quite rare) "feature not a bug" mentality in the open source world.
Yeah, but I personally don't want to read about myself like once a month - considering the brain dead bug I discovered yesterday in my code. ;)
To be fair: this code is only used by two people in the world, and for the other person this is not an issue as her data is formatted differently...
As developer I respect good testers as they can save you from a lot mistakes. The key is the system has to have different people do the development, code review, and testing even if it is because different people can interpret an ambiguous spec differently forcing someone to clarify what they want.
If your dad also goes by the name allthecoolshortnamesweretaken then I would imagine he has uncovered quite a few buffer overflows in his time.
That's just his first name. His surname is Smith '); DROP TABLE Comments;--
(and if the Reg comments system goes down after I click "submit", I will not know whether to laugh, cry, or flee the incoming vulture death-squads)
This also is the case for usability. Until something has been tried with a few real users you have absolutely no idea whether you've got it right or not. Until the people who think the monitor is the computer and switch it off when they go home, but leave the computer on - or who tell you that the email isn't working when they have a BSOD have tried it, it hasn't had real life testing.
Everyone (should) knows that opening attachments within e-mails that originate from unknown sources are best left unopened. So what could possibly go wrong here? :)
Even so... GPG4Win FTW. That's GnuPG for Windows (uses Kleopatra) and much to my first surprise it can hook directly into Outlook as well. And I'll take GPG over S/MIME any day of the week.
From what I remember, S/MIME-based encryption in Exchange was not intended for obfuscating the contents of the email. Instead, it was for validating that the original email was unchanged. From what I remember, being involved in writing the original RFC-style protocol documentation for Exchange, this was a known aspect of how S/MIME encryption worked. There always has to be some unencrypted part that leaked information, because the extended headers often contained identifiable information as well. How do you pass a public key in an extended header when all the extended headers are encrypted, was root of the problem, and the message-body was just a longer-length version of that same problem. That's why they eventually went to SMTP over HTTPS/TLC, so that the encryption encapsulated the entire connection.
Or, I could be remembering it wrong, too :D. But, this rings a loud, clear bell in my recollection.
S/MIME was designed both for message signature and encryption. It is known that some transport data need to be in cleartext because of course only the recipient has the key to decrypt a message - still the message "payload" is encrypted, and it is in the server storage as well.
Then the transport may happen over an encrypted channel to ensure confidentiality of the whole message - but unluckily now you can only protect that data from/to your mail client and your mail server - whatever happens outside your mail server is not under your control - the SMTP protocol really needs an update - there's a good chance no transport encryption will be used, and even it it is, there is no provision to check the certificates of the server you're talking to.
Microsoft claimed the exploitation of this bug was "unlikely" in the wild.
Mostly because S/MIME is an essentially dead protocol, that only a handful of people have ever bothered with....
S/MIME isn't dead. It's the standard protocol to use when encrypting internet mail within a PKI. The other common mail encryption protocol is PGP, but that isn't used within a PKI. If S/MIME is not much used it's because most people don't actually bother to encrypt their mail.
I would think that Microsoft regard exploitation of this bug as "unlikely" because they don't think anyone sends mail in plain text, nowadays.
If I could upvote this more, I would. Email is, and always has been, an unsecured plain-text protocol. You might be able to ensure you have SSL between you and your mail server, but then as far as the protocol is concerned, that SMTP server could be delivering the message to the next relay by semaphore, or by shouting it across a busy pub.
If you want to send something securely by email, send an encrypted attachment, don't depend on the protocol to do the work for you. Even then, you have to consider that your attachment in its encrypted form is visible to world+dog, and that if someone wanted to brute-force it they probably could, so a password-protected zip file isn't going to be much use to you unless you like typing in long high-entropy passwords.
You might be able to ensure you have SSL between you and your mail server, but then as far as the protocol is concerned, that SMTP server could be delivering the message to the next relay by semaphore
Technically true. However, many organisations require their partners, vendors, etc to prove that TLS is in use and enforced, or at least available opportunistically at each hop, mail system to getway, gateway to filtering service provider, and vice versa
... and I can now say with confidence, that Microsoft has given up on e-mail a long time ago. It still doesn't even have basic functionality like being able to display topic trees correctly.
Essentially all the things people hate about e-mail are implemented, and all the things people like about e-mail are missing.
Essentially all the things people hate about e-mail are implemented, and all the things people like about e-mail are missing.
MS GUIs seem to be more and more designed to piss off users... For instance, making the Configuration Panel much harder to access with Win10's 'Creator' (sic) update... WTF!
Essentially all the things people hate about e-mail are implemented, and all the things people like about e-mail are missing.
Isn't that just SOP with Microsoft. Find the stuff people like and then either screw it up or remove it completely. It's not the data capturing of Microsoft I've come to loath so much. ( They're all at it). It's that.
Microsoft went all-in with better quicksearch over threading, topics, manual organization and tags, etc, after Google completely blew away the idea of manually organizing mail for most of the population. It turns out that only about 1% actually care that much, the rest just want some way to access it. Granted Office 2007 sucked balls in almost every way, but most of the Outlooks since 2010 have been relatively solid if you don't need it to act like a 90's Usenet reader.
It is obvious that investment has stalled for a long time, though; the answer to most Outlook feature requests has been "Use Sharepoint!" for a decade now. Great, now I have two problems.
... But in this case given how easy the exploit is, and how far removed from the intended functionality, I can't help wondering if disclosing earlier would have been better so people could avoid sending more unencrypted emails that they believed were encrypted
Secure MIME has more support is easy to use but people like microsoft and Certificate Authorities are not helping...
why would you encrypt the same part of the message (formating) but not the other ?
I suspect that just a few gov offices will be asking a few questions...
I sent plain text email for many years but gave up when so many people complained, now every email from Outlook is ten pages of junk for two lines of text (if you view the source). Today I find Outlook's features mean I can send ten pages of obscured, poorly formatted HTML, and the plain text too!
I thought HTML was the height of inefficiency, but I had no idea.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
