> VeraCrypt has been licensed under the Apache License 2.0 since 28 June 2015.
> VeraCrypt inherited a substantial amount of code from its TrueCrypt predecessor and thus is also subject to the terms of version 3.0 of the "TrueCrypt License" which is unique to the TrueCrypt software.
Oh, their CodePlex site makes it look like a license change with no mention of the original license, which they might be violating, as the original license had numerous problems:
False.
See below.
Even if they wanted to enforce copyright, they can register as a pseudonym. They can also enforce in court under a pseudonym, as long as they can prove it's the same person with the registration.
For more interesting fun, read the last sentence of that PDF, where it goes on to explain that you get different years of protection for distributing under a pseudonym vs if your identity is revealed.
The first version of truecrypt that is vulnerable to the accessToken bug was 6.1a, which is roughly 4 years ago. I didn't look into the other bug though....4 years was enough for me....
If you want to do the digging into release dates, I would check this repo. This was the only archive of truecrypt code I could find.
https://github.com/DrWhax/truecrypt-archive
If you ask me, a much more serious bug would be going from an encrypted hard drive to an unencrypted hard drive... Local Privilege Escalation is definitely a bad bug, but it's not anywhere as bad as it could be.
Thanks. Truecrypt can do a lot of other stuff, too. I use it to en/decrypt a binary file in user mode on Linux, and nothing more, so I was wondering WTF this article was about.
Can someone explain why this is not just something that Microsoft should patch in windows? i.e how is this not just a windows vulnerability that you can use TrueCrypt to take advantage of? Why are drivers able to escalate privilege at all?
A driver is kernel-mode code that's written in C. It can do just about anything, and when there's a bug, you're in trouble.
I'd like to see Microsoft allow more drivers to run in user-mode, but this is just the risk you take when installing drivers. Microsoft has been tightening driver signing requirements, so you can at least be sure they're from a known source.
I did not realize how poorly the general "tech savvy" public apparently misunderstands software security.
Auditing is closer to an art than a science. For any real software, no two auditors will find the same set of bugs.
Think of it as similar to QA. If you write some complex software from scratch, and give it to 1 tester to do one pass on it, do you expect every bug was found and fixed?
Like security audits, you'll still be finding bugs for years, or in some cases even decades, that were sitting there all along.
Local machine privilege escalation and "full system compromise" are SOOOOOO vastly not of the same magnitude at all. This click bait title is obnoxious.
I don't even have non privileged users on my windows machine. Most end users don't. This could only really matter in some corporate environments but even my windows machine at work has full admin privileges.
Well, who is the target? Corporate and government customers are obviously important especially when we consider the various cyberwars going on and how much private and trusted data these companies have on us. Priv escalations are scary in my world. In the world of grandma's vacation photos? Not so much.
This is a major, major vulnerability, no doubt about it. Shame TC has a hackey Windows driver to make its pseudo-drive features work. Anything that installs a driver is dangerous in the world of Windows as it has high level permissions. I imagine organizations with strong security policies wouldn't run this and instead just run some PGP variant that doesn't use any customized Windows drivers.
>I don't even have non privileged users on my windows machine.
Technically, you do if you have the UAC enabled. You're only really an admin after UAC runs, at least in most cases. From what I'm reading this should work around he UAC if the driver is running at SYSTEM level.
