You're taking the p... Linux encryption app Cryptkeeper has universal password: 'p' Linux encryption app Cryptkeeper has a bug that causes it to use a single-letter universal decryption password: "p". The flawed version is in Debian 9 (Stretch), currently in testing, but not in Debian 8 (Jessie). The bug appears to be a result of a bad interaction with the encfs encrypted filesystem's command line interface: …
> Previously, encfs was bugged and didn't quite do this. A bugfix corrected its operation to match its documentation – which made it incompatible with Cryptkeeper's assumptions.
Seriously? The fact that there was a mismatch between the documentation and the behaviour of encfs didn't raise a flag to the Cryptkeeper dev(s)? Did they figure "this isn't a bug, its an undocumented feature"?
Crypto is hard...
> aaaaand ship..
Somewhere in the version history I imagine something like
Commit a1aa5eac-7dbd-4ff2-888e-9b9c619589fb
Temporary workaround for faulty '-S' switch in encfs.
TODO: remove workaround once encfs is updated
And as we know, nothing is more permanent than a temporary fix.
This is Linux. The documentation will be massively out of date and incomplete and, as we keep being told, you have the source so can find out what the code actually does.
In the absence of an documented API what was the app dev supposed to do?
I imagine encfs is actually quite well documented, but the vast majority of open source is so badly documented that just trying things and copying from Stackoverflow is the only way.
I'll offer up Zen, Zookeeper and Kafka as prime examples.
"In the absence of an documented API what was the app dev supposed to do?"
Look at the upstream source code. Find the problem. Fix it. Issue a pull request so the fix can be applied upstream. Follow the documentation. Release your product with a minimum requirement of 'upstream product version >= x.y.z'
Haha go upstream and fix it!!
First, the project owners will almost for sure reject my request, or ignore it.
Second, even if they do accept it, I will spend my time going upstream, and all th way to the kernel, jus to be insulted/derided by linus et al.
No, I will code arround the problem as I have been doing for the last 25 years, put a ToDo and a dependency, and inform the mantainer of the package, unless I have alredy informed them of other problems and I was ignored.
Each man to its post, that is the only way to be effective. I will not lose myself again fixing other peoples stuff, be it os or closed source.
"
Look at the upstream source code. Find the problem. Fix it.
"
Why do you assume that the error is with the code rather than the documentation? If the documentation for the OS's main input routine reads, "The space key will move the cursor destructively back one character", would you update the OS input routine to make that statement true, thus ensuring that every application on the system that uses a keyboard input will have users tearing their hair out, or would you correct the manual to read "backspace" instead of "space"?
Anyone who has bought any Chinese hardware would be ill-advised to modify the hardware so that it works the way the manual describes!
>The documentation will be massively out of date and incomplete and, as we keep being told, you have the source so can find out what the code actually does.
WTF? All documentation has out of date topics that need to be fixed, agreed. That is usually done when somebody, usually the developer who changed the code files a bug report for documentation to be adapted. You also have users noticing issues and creating bug reports ... that get fixed.
Compare that to Microsoft .... where 4 or 5 years ago, I combed through technet finding every single topic that mentioned CMD.EXE wildcards, posting a comment on each to say the doc on the ? wildcard is incorrect, dangerously incorrect.
Still incorrect to this day.
PS: I know MS nutters are following my posts on here, so expect it to be fixed within the next 5 months ... takes time to find somebody over in Redmond who does not panic when s/he sees a command prompt with a funny blinking bar - the only bloke they have capable of this feat is trying to configure an IPv6-only network.
>> takes time to find somebody over in Redmond who does not panic when s/he sees a command prompt with a funny blinking bar.
Eh...?
Have you used Windows Server, recently? There's this new-fangled, ten-year-old thingy called PowerShell, you see...
I guess your information is just a bit out of date! Please consider this a bug report and update it.
I love powershell. What I dont like about it is the huve number of bugs it has.
For me it is a fast way of doing comey scripting, disregarding performance. But man, it fails and doing what is promised in the documentation...sometimes in a subtle way, but some others in a clear way. I wonder what tests they do...
Oc, that means that i I change the version of ps my scripts might stip working..as they might work because ps works differently from the spec.. And if they fix it i am screwed...
Still, nice..and about my problems, eell, I found the bugs using google qfte a bit of frustation...it took some years for the ps team to fix obvious and reported bugs... And this makes ppl to code arround the bugs.
I see you follow the Trump method of addressing valid criticism; Point at someone else and some other entirely unrelated issue and wail "But what about them! Don't pick on me! Look at them!"
Fact is that Linux application documentation is frequently pathetically sparse and often out-dated, and your average developer does use "read the source" as an excuse for this situation.
Failings with Microsoft's documentation are an entirely different matter and completely irrelevant here.
Point at someone else and some other entirely unrelated issue and wail "But what about them! Don't pick on me! Look at them!"
Or how about this one: "Our code is flawless! All you have to do is replace all our libraries with ones from a licensed copy of Windows. If you don't like it, that's your problem."
Excel's VLOOKUP is another classic.
No documentation seems to get the difference between data and location where data is held.
No problem if you understand computer language design. PITA if you're anything more like an accountant.
CMD is being nudged away from its role in Windows scripting, so its bugs will be less of a problem.
Instead, there will be Powershell.
CMD bugs are not being fixed, because they're afraid to touch the code and break it worse. Also, people have scripts that their business runs on, that rely on bugs in CMD; if fixed, the scripts are liable to break., It's the same as the cryptkeeper situation.
I may regret asking: what is the issue with the ? wild card? I think I know of ambiguity as to whether specimen.txt needs wildcard of *.* to pick it up or just *, .
"WTF? All documentation has out of date topics that need to be fixed, agreed. That is usually done when somebody, usually the developer who changed the code files a bug report for documentation to be adapted. You also have users noticing issues and creating bug reports ... that get fixed."
That assumes that someone is monitoring the bug reports. I've experienced a few projects (admittedly not in the Linux arena) where people have filed bug reports only to find that the team working on the project isn't anymore, so the reports have gone unanswered. This hasn't happened in the case of encfs, but it does happen.
I've worked in various development projects, and found that developers can be the worst people to document their own code. I worked on one project where several systems (ranging from locally stored applications to web sites for different users with different functionality needed) hooked in to one core SOAP based webservice (they all needed some of the same core functionality, and all accessed an SQL database, and this was deemed to be the most efficient way to do that at the time). The webservice API had a couple of hundred functions. The user documentation for this API ran to one side of A4 paper.
The problem wasn't that the developers couldn't be bothered to update the documentation. The first release of the service had a fraction of the functionality of the final version, and no one on the team had time to update the documentation.
Not saying you are wrong. While I am a fairly experienced Linux user (although I actually use a combination of macOS and Windows day to day), I don't have enough knowledge to say for certain whether you are wrong or right. Just outlining that it's not as simple as saying that the developer files a bug report and the documentation is updated, even though that may happen in 90% of cases.
This whole thing is an example of where I think open source is not necessarily the best thing if you need guarantees.
If you buy software (be it an OS, Application, device driver, firmware etc), the law gives you a *lot* of protection should the software not live up to expectations, or fail in some way. I don't know the specifics, but I do know that you would be afforded protection by several acts (including, I think, the Sale of Goods act) of Parliament. You also have someone who would be considered liable should you decide to launch legal action. The companies in question also have some incentive (assuming the product is selling) to keep updating it, at least with security fixes.
The law does not give you any automatic protection when you install Open Source products. Most open source licences I have seen specifically state that the author of the product is not to be held liable for any damage done while the product is being used. You can buy/rent support from existing companies (IBM, Redhat etc), but I suspect any legal protection you get would be regarding the supply of that support rather than what the product does/does not do.
There is also the problem of what happens when the author of some software drops the project. This does happen in closed source software as well, but the larger closed source companies tend to advertise the fact they are dropping their products well in advance, at least to their enterprise customers, and they often provide security bug fixes for years after. I am not naive enough to assume that all companies do this. They don't. If they don't, and you launch legal action, you do have someone you can sue though.
This does not happen with Open Source. I am quite a fierce advocate for open source. I think it's a good thing, and when it works well, I think it's actually better for bug finding than closed source (as everyone who wishes to can look at the source code). The problem is that projects do often just die, with no updates from the developer and no updates from other users. At least if someone is paid to update it, they may be more likely to update it than if they aren't.
This is a problem security wise because people are told Open Source is inherently secure because everyone can view the code. This is what happened with Open SSL. As I understand it, a lot of companies included it in their products because it was assumed to be secure, then the heartbleed bug was found, and it turned out that people had filed bug reports before but the developers had not updated it. Yes, they rushed out a fix when the problem went public, but who would be held legally liable in the even of action.
According to to the Debian bug report, development for cryptkeeper seems to be dead.
So it's not that Debian is including a program who's developers are incompetent, it's that they're including a program that's no longer under active development and is now out of date.
This post has been deleted by its author
This post has been deleted by its author
... instead of using an API with parameters and checking them....
C'mon guys, it's no longer 1970, you have plenty of RAM now, you can keep some more code in it today, it doesn't make you a great programmer blindly believing in outdated practices just because some dinosaur who is utterly afraid to learn anything new told you so.
>Ah, the old and outdated Unix method of chaining executables...
>... instead of using an API with parameters and checking them....
>C'mon guys, it's no longer 1970, you have plenty of RAM now, you can keep some more code in it today, it doesn't make you a great programmer blindly believing in outdated practices just because some dinosaur who is utterly afraid to learn anything new told you so.
Lennart, hau jetzt bitte ab, ja, komme nicht zurück, deine Meinung zählt hier nicht.
...instead of using an API with parameters and checking them....
I was thinking exactly the same thing. Command line interfaces are a particularly crummy way of calling code.
I also shudder to think what can possibly go wrong when someone changes their code's interface in python, Javascript, etc.
Strongly typed languages are a much better idea.
You don't need a strongly typed language to have a clear and unambiguous interface.
The interface to this executable is confused and badly defined, but that doesn't make all command line interfaces shit. Just having a clear distinction between parameter names and parameter values would be good enough. Clarity is much more important than brevity.
So, it looks like cryptkeeper called encfs in a way the encfs man page specifically warn against. Thats brave. The -S option should not be used unless the encrypted file system already exits. Otherwise the interaction of deciding how to make it and setting a password is too complicated, too much risk of the sort of problem we see now.
But now the encfs people are talking of reverting the change. Sigh
Maybe they should rely on an expect script ? So much more reliable....
Well that depends... If the version of cryptkeeper being used in the test versian of debian is also a test release then yes, that is what tests are for. If, however its intended as a shipping release, and worse, if other distributions are using that version of cryptkeeper that are beyond test release status...
I'm torn between thinking expect would help, and thinking it just adds another layer of undocumented changes that can break things.
The fact is scripting command line tools is inherently fragile, often gives ambiguous results, and can easily result in security holes. It's the first resort of most *nix programmers but really should be the last.
In general as a rule of thumb try to use the tools that come by default with the Tails OS iso as those people put a lot of thought into this stuff. Its the main reason why I started using Keepassx. As for encrypting files and directories why anyone comfortable with the CLI would use anything but tar and GPG2 or ecryptfs or dm-crypt is beyond me
+1 dm-crypt
Why anyone would ever store an unencrypted copy of anything worth encrypting is beyond me. Well, unless it's always held in a ramdisk, so the plaintext never hits anything long-term-- and any swap is also encrypted.
All you need is for some sector to be silently reallocated before or during shred'ing and some determined investigator will in fact have something to find even if they never find it. So some precious certainty is already gone if you ever keep plaintext, until you personally destroy the platters (if/f you're on spinny rust like me)
I've always wondered why no one has built a system with a small chunk of RAM that is battery backed specifically to hold sensitive encryption data. The battery-backing would be there not to preserve the memory in case of power loss, but rather the exact opposite: overwrite the memory piece several times after power has been cut. Wouldn't need any modification to the system other than sticking a battery on a RAM module (Since DDR modules have controllers on board) and some flags in its ID string so the OS knows that it is a secure module that can be used as such. Memory modules' controllers already have an I2C bus connection that the OS has access to, so the OS could even mark specific regions of the module as containing secure data so the module can prioritize those.
I have seen far too many OSes and applications that don't bother to over-write sections of memory that held encryption keys so they stay in there after a reboot. While debugging boot code (I've been working on the coreboot/libreboot project) I keep seeing keys in my memory dumps surrounded by bits of plain text making it obvious what that random data is (I even compared the memory dump to the .key files and its an exact match).
I've even seen attacks that intentionally cause the OS to core-dump / bluescreen just so the attacker can read from previously-protected sections of memory (funny enough, some OSes will actually intentionally dump when some tries to access those protected bits of memory but will just write all memory out when it does coredump).
Apparently for SSDs "shred" or old-school secure deletion is entirely futile. I kinda wondered, now I wonder if there are any that advertise it and deliver.
But self-sanitizing RAM, that sounds like a good idea-- though I would rather just blow it all away, no need to mark off anywhere as being sensitive (the big glowing sign says SPECIAL STUFF HERE). If you can get away with it being buffered or registered, the DIMM already has an extra IC so that only needs another function tacked on and it only needs a few seconds to zero everything. You'd also probably need it to analyze access patterns in order to decide if the machine is panicked, wedged, or just asleep-- unless you always get notifications over I2C, and then which ones do you trust? Also it would be good to sense at the connector whether someone injected their own power to defeat the scrubber and tried to pluck the DIMM out in order to casually read it. Yes I would :) And then, if the battery isn't e.g. a supercapacitor in the IC's *die*, how do you keep someone from merely neutering it?
While the article implies that "p" is a sort of "master password" that can be used instead of the intended password, if I have understood the bug correctly, any password that is entered to create or open an encrypted folder will be substituted by the letter "p". In which case typing any password at all would open the folder. So it is not an additional password, but is the only password assigned to all encrypted folders.
If my understanding is correct, did the programmer never deliberately enter a wrong password to ensure that it will not unlock the folder? Or even use it to any great extent? I regularly hit the "return" key just as I realise that I have mis-typed a password (or typed the wrong password), and so would soon know something was amiss if that resulted in opening the encrypted file (or logging onto a password protected system etc.)
Y'know, there is a bug report which explains all of these things. It's even linked from the article.
Here, I'll read it for you. Cryptkeeper calls encfs to create an encrypted filesystem interactively and feeds it answers through stdin. The code is even included in the bug report:
execlp ("encfs", "encfs", "-S", crypt_dir, mount_dir, NULL);
exit (0);
[...]
// paranoid default setup mode
//write (fd[1], "y\n", 2);
//write (fd[1], "y\n", 2);
write (fd[1], "p\n", 2);
write (fd[1], password, strlen (password));
write (fd[1], "\n", 1);
Not only does it answer "p" to the "Paranoid or eXpert mode?" prompt, it also used to answer "y" twice before that, presumably to answer questions about creating the filesystem and mount point specified in crypt_dir and mount_dir. The man page for encfs even specifically warns about that possibility:
-S, --stdinpass
Read password from standard input, without prompting. This may be useful for scripting encfs mounts.
Note that you should make sure the filesystem and mount points exist first. Otherwise encfs will prompt for the filesystem creation options, which may interfere with your script.
The end result of this is that Cryptkeeper will ignore the user supplied passphrase and create an encrypted filesystem with the password "p". Since the error was restricted to the creation code, any further attempts to mount the newly created filesystem with the correct password would fail.
While the real source of this error is the sloppy use of an interactive session with encfs in Cryptkeeper, the trigger was a recent fix made to encfs which removed the "paranoid?" prompt. Since this fix was committed on December 12th, when Cryptkeeper was no longer maintained, it was not caught until the next time a Debian testing user tried to create a new encrypted filesystem and found that it didn't work.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
