advisory: Private key leak via inherited file descriptor

Author: joeyh

advisories/hackage/crypton/HSEC-0000-0000.md

@@ -0,0 +1,36 @@
+```toml
+[advisory]
+id = "HSEC-0000-0000"
+keywords = ["crypto"]
+[[references]]
+type = "FIX"
+url = "https://github.com/kazu-yamamoto/crypton-certificate/commit/e353d450c381c9d6b903c4257927e0c89c97acb1"
+
+[[affected]]
+package = "cryptonite"
+cvss = "CVSS:4.0/AV:L/AC:H/AT:P/PR:L/UI:P/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N"
+[[affected.versions]]
+introduced = "0.1"
+
+[[affected]]
+package = "crypton"
+cvss = "CVSS:4.0/AV:L/AC:H/AT:P/PR:L/UI:P/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N"
+[[affected.versions]]
+introduced = "1.6.9"
+fixed = "1.6.12"
+
+```
+
+# Private key leak via inherited file descriptor 
+
+The X509 key reading function readKeyFile opened a file descriptor to the
+private key without setting the close-on-exec flag. If a child process is
+execed at the same time, it would inherit that file descriptor and could
+read the private key material.
+
+Impact is limited to child processes that drop permissions before running
+untrusted code, but that do not close inherited file descriptors. (For
+example, the "su" command.)
+
+This leak was fixed by setting the close-on-exec flag on unix-based
+systems.