Security improvement

[jlodos]

In the function CCID_Transmit there is a local buffer where the command is copied. The memory assigned for that buffer remains unchanged for a long time after the function exited. In a situation where the command contains the pin, the pin will remain in memory for a long time. New commands will allocate different buffers in the stack. Furthermore, the interesting buffer will be at a fixed memory, so an attacker can find this memory offset using a known pin/card.
This problem was observed when auditing some process memory searching for long standing secrets.
One possible solution is cleaning up the buffer after use. Something like:

#if defined(__APPLE__)
    memset_s(cmd, 10+tx_length, 0, 10+tx_length);
#elif defined(__linux__) && (__GLIBC__ > 2 || (__GLIBC__ == 2 && __GLIBC_MINOR__ >= 25))
    explicit_bzero(cmd, 10+tx_length);
#else
    static void* (*volatile s_memset)(void*, int, size_t) = memset;
    s_memset(cmd, 0, 10+tx_length);
#endif

An alternative solution is to request extra space in the user provided buffer and avoid a local one. But I guess this will break backward compatibility.
Thank you.

[LudovicRousseau]

The CCID driver is running in the pcscd process as root.
So you have to get root access to read the pcscd process memory. Exact?

[jlodos]

It is used not only in the pcscd process. It is also used from SCardTransmit in PCSClite. This is our use case, we are using PCSClite as a library. If you access the process memory you can see the pin there long after all our buffers were cleaned up.

[LudovicRousseau]

libpcsclite.so.1 is a library. Exact.
The buffer pointed by the parameter pbSendBuffer of SCardTransmit() is NOT copied/duplicated. It is the job of the application to clean the buffer after the call to SCardTransmit().
Or maybe I missed your point.

[jlodos]

The buffer being copied was the point 😄. SCardTransmit calls IFDHTransmitToICC. IFDHTransmitToICC calls CmdXfrBlock. CmdXfrBlock calls CCID_Transmit. CCID_Transmit makes a copy of the buffer.

[LudovicRousseau]

I agree with you. But the buffer copy occurs on the daemon side run as root.
I do NOT see any problem on the libpcsclite.so.1 side.

[jlodos]

Because libpcsclite.so is loaded into the process memory, the buffer is also created in a process memory address. There is no IPC, just a chain of calls.

[LudovicRousseau]

Please show me the line of code that creates the buffer in libpcsclite.so.

[jlodos]

It is the one I linked before. This one.

[jlodos]

The buffer declaration is here.

[LudovicRousseau]

It is NOT in libpcsclite.so.
Please try again.

[jlodos]

I am not sure what you mean. This code is linked in libpcsclite.so. There is no IPC, just a chain of calls. The call from PCSCLite sources is here.

[LudovicRousseau]

Can you share the security audit report? I would like to read it.

[jlodos]

Unfortunately no, sorry. Please note there is no claim of a vulnerability, as secrets in memory are expected if your program manages them. Just trying to reduce the time that secrets (the pin in this case) remains in memory. Trying to minimize exploits of mismanaged memory dumps and the risk when users incorrectly let other users to use their sessions.

[LudovicRousseau]

If you are afraid your PIN code can leak I suggest to use a pinpad reader.
https://ccid.apdu.fr/select_readers/index.html?features=PIN%20Verification

[jlodos]

Unfortunately not all users of the program can be told to acquire such a reader.

[jlodos]

Would a PR help to address the issue?

[LudovicRousseau]

I would like to be convinced it is a real problem.
Can you provide an exploit source code that extract the PIN code value (by a non root user) for example?

[jlodos]

Thank you for your answer. I can create such program. Is there a way I can contact you privately?

[LudovicRousseau]

My email is listed at https://blog.apdu.fr/articles/about_me/