New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
security bug: decryption attack #271
Comments
|
Ok, this works even for a very simple minded attacker. Prerequisites for the victim: Automated encrypted setup. Prerequisites for the attack: Write access to the backup target. Steps to reproduceVictim preparesThe victim now sets up a cron job to regularly execute Attacker preparesVictim does the next backupAttacker reaps data |
|
Why is automated backup a requirement for successful exploitation? Just because the user isn't prompted for the password and is therefore able to recognize the attack? |
|
Yeah, It's not a requirement per se. It's just that, when not using ATTIC_PASSPHRASE as I did in the example, the user might notice that there's no passphrase prompt. (Of course, they might just not notice even in the manual case.) On the topic of telltale signs: Note that |
Yeah, my life seems to be slowing down a bit lately so I'm optimistic to be able to release 0.15 as a bug fix release (this and other fixes) in a couple of days. The fix I just pushed forces users to manually approve first access of unknown (no cache dir on disk) unencrypted repositories. UX wise this sucks, but we have no choice I guess... One more thing, as with most open source projects it's best practice not to discuss security related topics in public. Contact me directly instead. |
|
Why not HMAC all the configuration etc. that's stored server-side? |
|
@fw42 hmacs are (only) used if crypto keys are available, but the issue here is that the untrusted backup repo server is telling "this is unencrypted", so attic would not switch into the correct "mode". @jborg about disclosure you're completely right. When @henryk and me sat together at EH15 we first thought this only MIGHT be an issue (and if it was one, it might be complicated to tweak the repo to exploit it). Then I filed an issue about it so that we do not forget to look at this later. It was a bit unexpected that (shortly afterwards) it turned out to be really an issue and even that easy to trigger. On the way back home from EH15 I thought about how to fix that best and that maybe defaulting to encryption ON and a cmdline option to explicitly switch it off would be the best: Without that option, attic would not initialize an unencrypted repo / create an unencrypted backup. |
|
In case somebody tries to reproduce whether the fix really works: it is important to either use different users or to at least make sure that victim's ~/.cache/attic is kept separate from attacker's ~/.cache/attic. If you use same user (as I did when first trying), attic won't ask questions as it will know that the switch to unencrypted came from the current user. So, I can confirm now that the fix works. \o/ |
|
Does this create problems if I move a repository to a different path? I'm getting a warning from a cron script (which makes the backup fail, obviously). And there seems to be no create --unencrypted. The repository has never been encrypted. |
|
FYI, CVE-2015-4082 has been assigned to this issue. |
assume attacker has access to your (still) encrypted repository and changes the manifest type byte to "unencrypted / without key file".
your next automated backup will then run in unencrypted mode without you noticing it and you give all your data to the attacker who controls your backup device.
The text was updated successfully, but these errors were encountered: