LightDM keeps plain text login password in memory

Any update on this?

Thanks for subscribing us Sven, this bug was invisible until then.

BTW, is there a reason to keep this bug private? It doesn't directly allow privilege escalation, it feels like the privacy is unneeded here.

Thanks

That is up to you, I just felt to rather be cautious just in case this has side effects I am not aware of. :)

I suppose most of the time authentication childs actually exit? There's a lot of indirection in the source because it's a child that communicates with the greeter through another daemon. But AFAICS it expects PAM to free() the strings:

        // callers of this function inside pam will expect to be able to call
        // free() on the strings we give back. So alloc with malloc.
        r->resp = read_string_full (malloc);

And hence there's no scrubbing: It expects PAM to do that. But if we look at the documentation:

       The other arguments of a call to conv() concern the information
       exchanged by module and application. That is to say, num_msg holds the
       length of the array of pointers, msg. After a successful return, the
       pointer resp points to an array of pam_response structures, holding the
       application supplied text. The resp_retcode member of this struct is
       unused and should be set to zero. It is the caller's responsibility to
       release both, this array and the responses themselves, using free(3).
       Note, *resp is a struct pam_response array and not an array of
       pointers.

       The number of responses is always equal to the num_msg conversation
       function argument. This does require that the response array is
       free(3)'d after every call to the conversation function. The index of
       the responses corresponds directly to the prompt index in the
       pam_message array.

Naively I'd say that the callback approach as implemented in lightdm is actually leaking the memory because it calloc()s the responses array in the callback and then passes the pointer to PAM to be done with it. Hence there's also nothing that'd go and scrub the memory afterwards.