Ubuntu
ecryptfs-utils package

ecryptfs private wrapped passphrase with wrong password during password change

Bug #305882 reported by joshua pritikin
16
This bug affects 2 people
Affects Status Importance Assigned to Milestone
ecryptfs-utils (Ubuntu)
Invalid
Undecided
Unassigned
pam (Ubuntu)
Fix Released
High
Steve Langasek

Bug Description

Binary package hint: ecryptfs-utils

To reproduce:

1. On command line, attempt to change your password to a weak password (like "yes").
2. Actually change your password to a strong password.

I found that ecryptfs wrapped the passphrase in the weak password instead of the final password I chose.

Description: Ubuntu 8.10
Release: 8.10

ecryptfs-utils:
  Installed: 53-1ubuntu12
  Candidate: 53-1ubuntu12
  Version table:
 *** 53-1ubuntu12 0
        500 http://mirrors.us.kernel.org intrepid-updates/main Packages
        100 /var/lib/dpkg/status
     53-1ubuntu11 0
        500 http://mirrors.us.kernel.org intrepid/main Packages

Tags: pet-bug

Related branches

lp:ubuntu/karmic/pam
Revision history for this message
Vernon Tang (vtang) wrote :

Confirmed on Jaunty (ecryptfs-utils 68-1ubuntu1).

Changed in ecryptfs-utils:
status: New → Confirmed
Revision history for this message
Dustin Kirkland  (kirkland) wrote :

Subscribing Steve Langasek...

Steve,

This is yet another case of badness regarding PAM's architecture. I can confirm this problem, and it's a nasty one.

The ecryptfs PAM module thinks that the password change succeeded, and so we go ahead and rewrap the passphrase, but this isn't so.

We need to get this fixed...

:-Dustin

Revision history for this message
Dustin Kirkland  (kirkland) wrote :

<slangasek> 16:32:27> +kirkland: could you provide a transcript of a session showing bug #305882?

Hmm, Steve, per your request, I tried to reproduce this on an Intrepid (and a Jaunty) system, and actually, I'm not able to reproduce it...

foo2@intrepid:~$ passwd
Changing password for foo2.
(current) UNIX password: foobar
Enter new UNIX password: yes
Retype new UNIX password: yes
You must choose a longer password
Enter new UNIX password: foobar123
Retype new UNIX password: foobar123
passwd: password updated successfully
foo2@intrepid:~$ ecryptfs-unwrap-passphrase ~/.ecryptfs/wrapped-passphrase
asdfasdfasdf

jpritikin73-

Could you please provide a similar log to the one I did above? Please scrub it clean of any real passwords!

:-Dustin

Changed in ecryptfs-utils:
status: Confirmed → Incomplete
Revision history for this message
Vernon Tang (vtang) wrote :

victim@stupid:~$ ecryptfs-unwrap-passphrase ./.ecryptfs/wrapped-passphrase
Passphrase: password
Warning: Using default salt value (undefined in ~/.ecryptfsrc)
(passphrase)victim@stupid:~$ passwd
Changing password for victim.
(current) UNIX password: password
Enter new UNIX password: a
Retype new UNIX password: a
You must choose a longer password
Enter new UNIX password: a
Retype new UNIX password: a
You must choose a longer password
Enter new UNIX password: a
Retype new UNIX password: a
You must choose a longer password
passwd: password updated successfully
victim@stupid:~$ ecryptfs-unwrap-passphrase ./.ecryptfs/wrapped-passphrase
Passphrase: password
Warning: Using default salt value (undefined in ~/.ecryptfsrc)
Error: Unwrapping passphrase failed [-5]
Info: Check the system log for more information from libecryptfs
victim@stupid:~$ ecryptfs-unwrap-passphrase ./.ecryptfs/wrapped-passphrase
Passphrase: a
Warning: Using default salt value (undefined in ~/.ecryptfsrc)
(passphrase)victim@stupid:~$ su victim
Password: a
su: Authentication failure
victim@stupid:~$ su victim
Password: password
victim@stupid:~$

Revision history for this message
Dustin Kirkland  (kirkland) wrote : Re: [Bug 305882] Re: ecryptfs private wrapped passphrase with wrong password during password change

Ah, okay...

So the problem occurs after making the same mistake 3 times.

Steve?

:-Dustin

Revision history for this message
Dustin Kirkland  (kirkland) wrote :

This is a bug in PAM, about to fixed by an upload by slangasek \o/

:-Dustin

Changed in ecryptfs-utils:
status: Incomplete → Invalid
Changed in pam:
assignee: nobody → vorlon
importance: Undecided → High
status: New → In Progress
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package pam - 1.0.1-5ubuntu2

---------------
pam (1.0.1-5ubuntu2) jaunty; urgency=low

  * New patch dont_freeze_password_chain, cherry-picked from upstream:
    don't always follow the same path through the password stack on
    the PAM_UPDATE_AUTHTOK pass as was used in the PAM_PRELIM_CHECK
    pass; this Linux-PAM deviation from the original PAM spec causes a
    number of problems, in particular causing wrong return values when
    using the refactored pam-auth-update stack. LP: #303515, #305882.

 -- Steve Langasek <email address hidden> Fri, 27 Feb 2009 16:20:24 -0800

Changed in pam:
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.