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
Printing server secret key in plain text in journalctl #149
Comments
|
We are printing this here: Line 377 in e1f842c
|
If journald for syslog the journal is going to store everything, even DEBUG loglevel messages. Pre-journald this could be avoided. Fix kravietz#149 Signed-off-by: Daniel Gollub <dgollub@att.com>
If journald for syslog is used, the journal is going to store everything, even DEBUG loglevel messages. Pre-journald logging of system-wide DEBUG loglevel could be avoided and is not affected in all cases. With journald presence it's probably safe to no longer log sensitive details at DEBUG level. Fix kravietz#149 Signed-off-by: Daniel Gollub <dgollub@att.com>
|
IIUC this affects "only" journald environments. Pre-journald are not affected, unless they store/log the DEBUG loglevel for this particular facility. https://tools.ietf.org/html/draft-ietf-opsawg-tacacs-18#section-10.1 ... this is not encryption, this is obfuscation :) But yes, this might could be considered a security vulnerability, if the pam_tacplus module is used in a journald environment. Stock libtac users would be not affected, only pam_tacplus users. @kravietz how was such things handled in the past? CVE? |
|
The secret is stored in the configuration file anyway, so if you've got access to the server and can see it in the logs, it's game over anyway. Alternatively, if you've got |
|
Hello everyone, First off, it's great that this was fixed so quickly. Thank you for that! I think that regardless of the strength of the protocol and regardless of how the key is stored, logging secrets is generally considered a security issue. I think that users of this module would need a clear note that this was happening and they can make up their minds from there. A CVE is the traditional vehicle to deliver that message. https://cwe.mitre.org/data/definitions/532.html shows examples of prior times where this was considered an issue and a CVE was opened. |
|
@kravietz , would now be a good time to release 1.5.2? I could drive the CVE assignment / disclosure on oss-security, if you like? |
|
@gollub This is a very good point, if you have capacity the do CVE then sure, go for it and we can bump the version to 1.5.3 with the new CVE info so it's properly picked up by downstream distros. |
|
Could you release 1.5.2/3? The MITRE form asks for a fixed version. |
|
Done |
Following kravietz#149 remove the debug option from the example PAM configs, to avoid accidental use by copy-paste.
|
@gollub Is CVE for this filed yet? If it is filed, can you please provide the CVE ID here. If not and if it's not an effort, can you please in the CVE for originally finding it as "Adarsh Pandey from Arista Networks"? |
|
CVE-2020-13881 was assigned for this issue. |
|
@the-magician , yes I filed the CVE request Friday morning (CET), MITRE assigned CVE-2020-13881 Saturday evening (CET). With respect to the credit and CVE/MITRE: https://cve.mitre.org/about/faqs.html#does_cve_entry_credit_discoverer But I referred you as the original reporter in the oss-security mail, which I just send. |
In the example, we can see that server secret key is printed in plain text in journalctl logs. If an attacker is using man-in-the-middle attack and somehow gets these logs, he/she can decrypt and see all packets. User passwords will also be exposed by that.
The text was updated successfully, but these errors were encountered: