org-crypt.el security problem (From: Milan Zamazal)

org-crypt.el security problem (From: Milan Zamazal)

[Peter Jones]

Here is an email I received from Milan Zamazal:

,----
| I don't know whether you are aware of this, but I consider it a serious
| security problem of org-crypt.el in (at least) Emacs 23.2:
| 
| I've found out that when I edit a (decrypted) crypt entry and the edited
| file is autosaved, the autosaved file contains the given crypt entry in
| plain text.  So unless the user has got a special arrangement of storing
| autosave files to a secure location where they are also deleted
| securely, the secret content may be accessed either in the autosave file
| directly, or it may be later retrieved by an off-line attacker from the
| deleted file content that remained stored somewhere on the disk.
| 
| This should be fixed or at least a big warning should be placed in
| org-crypt.el.
`----

I don't have time to look into this.  Would someone please see if there
is a way to prevent it.  Off the top of my head, the only thing I can
think of is disabling autosave for any org buffer that uses org-crypt.

Hopefully there's an autosave hook where you can encrypt the headings
and save to disk using a temporary buffer without having to alter the
current buffer and interrupt the user by encrypting a heading that is
being edited.

-- 
Peter Jones - pmade inc.
303-219-0226 http://pmade.com

Re: org-crypt.el security problem (From: Milan Zamazal)

[Julien Danjou]

[-- Attachment #1: Type: text/plain, Size: 587 bytes --]

On Fri, Mar 04 2011, Peter Jones wrote:

> Hopefully there's an autosave hook where you can encrypt the headings
> and save to disk using a temporary buffer without having to alter the
> current buffer and interrupt the user by encrypting a heading that is
> being edited.

I've recently added caching of encrypted text, so that org-crypt will
not recrypt the text once again if it has not been modified, but reuse
the previous crypting value.

That could be used to automagically re-encrypt all text before
auto-saving.

-- 
Julien Danjou
❱ http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: org-crypt.el security problem (From: Milan Zamazal)

[Bastien]

Hi Peter,

Peter Jones <mlists@pmade.com> writes:

> Here is an email I received from Milan Zamazal:
>
> ,----
> | I don't know whether you are aware of this, but I consider it a serious
> | security problem of org-crypt.el in (at least) Emacs 23.2:
> | 
> | I've found out that when I edit a (decrypted) crypt entry and the edited
> | file is autosaved, the autosaved file contains the given crypt entry in
> | plain text.  So unless the user has got a special arrangement of storing
> | autosave files to a secure location where they are also deleted
> | securely, the secret content may be accessed either in the autosave file
> | directly, or it may be later retrieved by an off-line attacker from the
> | deleted file content that remained stored somewhere on the disk.
> | 
> | This should be fixed or at least a big warning should be placed in
> | org-crypt.el.
> `----
>
> I don't have time to look into this.  Would someone please see if there
> is a way to prevent it.  Off the top of my head, the only thing I can
> think of is disabling autosave for any org buffer that uses org-crypt.
>
> Hopefully there's an autosave hook where you can encrypt the headings
> and save to disk using a temporary buffer without having to alter the
> current buffer and interrupt the user by encrypting a heading that is
> being edited.

Actually that would be nice, but there is no such hook.  
Only `auto-save-hook', which operates on the visited buffer.

I didn't find a satifactory way of dealing with this issue.  

For now, loading org-crypt will send a warning advising the
user to turn auto-save-mode off in org buffers containing 
crypted entries.

Thanks for bringing this up,

-- 
 Bastien

Re: org-crypt.el security problem (From: Milan Zamazal)

[Bastien]

Hi Julien,

Julien Danjou <julien@danjou.info> writes:

> On Fri, Mar 04 2011, Peter Jones wrote:
>
>> Hopefully there's an autosave hook where you can encrypt the headings
>> and save to disk using a temporary buffer without having to alter the
>> current buffer and interrupt the user by encrypting a heading that is
>> being edited.
>
> I've recently added caching of encrypted text, so that org-crypt will
> not recrypt the text once again if it has not been modified, but reuse
> the previous crypting value.

I've seen org-encrypt-string but I don't see we could use it for the 
problem at hand.  

Also, the purpose is to encrypt the auto-saved buffer and *not* the
visited buffer -- which I don't know how to do.  

> That could be used to automagically re-encrypt all text before
> auto-saving.

Please let us know if you can think of a better fix than the warning!

Thanks,

-- 
 Bastien

Re: org-crypt.el security problem (From: Milan Zamazal)

[Julien Danjou]

[-- Attachment #1: Type: text/plain, Size: 1063 bytes --]

On Sun, Mar 06 2011, Bastien wrote:

> I've seen org-encrypt-string but I don't see we could use it for the 
> problem at hand.  

Just saying that if you don't use it, youe re-encryption on auto-save
will ask the user for its passphrase if he is not using any agent.

> Also, the purpose is to encrypt the auto-saved buffer and *not* the
> visited buffer -- which I don't know how to do.  

Add org-encrypt-entries to auto-save-hook and org-decrypt-entries-which
were-not-decryped to after-auto-save-hook… which does not seems to
exist. :)


What I can also suggest is to never show the encrypted block in the Org
buffer.

This is what I do in my configuration: on Org file loading, I decrypt
all entries. Therefore I never see the GPG block. When I save,
everything is encrypted, written, and then re-decrypted.

Using org-crypt this way, it would be easy to fix auto-save-hook. With
the current way on letting the user decrypt heading by heading, it does
not seems that easy. :)

-- 
Julien Danjou
❱ http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: org-crypt.el security problem (From: Milan Zamazal)

[Bastien]

Hi Julien,

Julien Danjou <julien@danjou.info> writes:

> What I can also suggest is to never show the encrypted block in the Org
> buffer.

I agree this would be better.

> This is what I do in my configuration: on Org file loading, I decrypt
> all entries. Therefore I never see the GPG block. When I save,
> everything is encrypted, written, and then re-decrypted.

Can you share your config?

> Using org-crypt this way, it would be easy to fix auto-save-hook. 

I see: auto-save-hook would encrypt, write to ~/.#file# then decrypt the
original buffer back again -- yes?

> With the current way on letting the user decrypt heading by heading,
> it does not seems that easy. :)

Yep...

-- 
 Bastien

Re: org-crypt.el security problem (From: Milan Zamazal)

[Julien Danjou]

[-- Attachment #1: Type: text/plain, Size: 1253 bytes --]

On Sun, Mar 06 2011, Bastien wrote:

>> What I can also suggest is to never show the encrypted block in the Org
>> buffer.
>
> I agree this would be better.
>
>> This is what I do in my configuration: on Org file loading, I decrypt
>> all entries. Therefore I never see the GPG block. When I save,
>> everything is encrypted, written, and then re-decrypted.
>
> Can you share your config?

NO WAY!

But here it is:

#+begin_src emacs-listp
(org-crypt-use-before-save-magic)
(defun jd:org-decrypt-everything-silently ()
  (let ((m (buffer-modified-p)))
    (org-decrypt-entries)
    (unless m
      (set-buffer-modified-p nil))))
(add-hook 'org-mode-hook 'jd:org-decrypt-everything-silently)
(add-hook 'org-mode-hook (lambda ()
                           (add-hook 'after-save-hook 'jd:org-decrypt-everything-silently)))
#+end_src

- Loading org-mode on a file decrypt everything;
- Saving encrypt everything (org-crypt-use-before-save-magic adds this);
- After-saving we re-decrypt.

Using this method with auto-save-hook should be possible.

> I see: auto-save-hook would encrypt, write to ~/.#file# then decrypt the
> original buffer back again -- yes?

Yup.

-- 
Julien Danjou
❱ http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]