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
CVE-2020-35766: Insecure temporary key path /tmp/testkeys #113
Comments
|
Curious why this would be assigned a CVE. Tests are not part of the deployed software, so it's not possible to exploit this. |
|
It's exploitable whenever/wherever the test suite is run. If I You're correct that you don't need to worry about this in a binary deb package, for example... but the guy building the deb needs to worry about it. |
|
The CVE is "under investigation" -- and targets the test suite as was
noted.
I'm on vacation till the 6th of January, and will hold off taking any
action until the CVE is accepted/tested or resolved/rejected.
…-Martin
On Tue, Dec 29, 2020 at 1:15 PM Michael Orlitzky ***@***.***> wrote:
It's exploitable whenever/wherever the test suite is run. If I git clone
the repo and run the test suite, it's exploitable on my machine. In other
words, the code is exploitable in 100% of the situations where it's used.
And, for example, the test suite optionally run whenever a Gentoo user
installs OpenDKIM.
You're correct that you don't need to worry about this in a binary deb
package, for example... but the guy building the deb needs to worry about
it.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#113 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAB5KKKYLUJ4BQE3MVDIAVDSXITEPANCNFSM4VMGCUFQ>
.
|
|
The CVE being issued doesn't mean much on its own... the number is just a way for everyone to refer to one vulnerability in a consistent way. (If you think the issue itself is invalid, it can be disputed.) That the issue is exploitable is clear: create a symlink from |
|
Michael,
That requires something to be run "as root" which is unacceptable on _any_
system by basic security measures. On that principle alone, the CVE is
basically not valid. If an exploit requires you to run something _as_ root
for it to work in the first place, it's an error in procedure. Not an
exploit.
…On Tue, Dec 29, 2020 at 1:38 PM Michael Orlitzky ***@***.***> wrote:
The CVE being issued doesn't mean much on its own... the number is just a
way for everyone to refer to one vulnerability in a consistent way. (If you
think the issue itself is invalid, it can be disputed.)
That the issue is exploitable is clear: create a symlink from
/tmp/testkeys to /etc/passwd as any unprivileged user (nobody, www,
etc.). Then run the test suite as root. Now your system is borked.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#113 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAB5KKIG7MBIMMOZ6ZRXGXTSXIV2RANCNFSM4VMGCUFQ>
.
|
|
If you wish to repair the issue and submit a patch/PR, I'll look at it.
Otherwise, this is a "doctor, it hurts when I do this" kind of bug ...
don't run test suites as root.
On Tue, Dec 29, 2020 at 1:42 PM Martin Bogomolni <martinbogo@gmail.com>
wrote:
… Michael,
That requires something to be run "as root" which is unacceptable on _any_
system by basic security measures. On that principle alone, the CVE is
basically not valid. If an exploit requires you to run something _as_ root
for it to work in the first place, it's an error in procedure. Not an
exploit.
On Tue, Dec 29, 2020 at 1:38 PM Michael Orlitzky ***@***.***>
wrote:
> The CVE being issued doesn't mean much on its own... the number is just a
> way for everyone to refer to one vulnerability in a consistent way. (If you
> think the issue itself is invalid, it can be disputed.)
>
> That the issue is exploitable is clear: create a symlink from
> /tmp/testkeys to /etc/passwd as any unprivileged user (nobody, www,
> etc.). Then run the test suite as root. Now your system is borked.
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <#113 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAB5KKIG7MBIMMOZ6ZRXGXTSXIV2RANCNFSM4VMGCUFQ>
> .
>
|
Replace "root" with the username of your choosing. Should random unprivileged accounts on the machine be able to delete his files? |
|
https://bugzilla.redhat.com/show_bug.cgi?id=1911496 (tracking bug) I'll hold off adjusting the packages in Fedora & EPEL until upstream has a recommended resolution. |
|
@mdomsch unless your users can run the test suite somehow, this probably doesn't affect your RPMs. |
|
@martinbogo there are a few ways to fix this, and some of them interact with #110. If the test keys never change, one easy option would be to commit them to git, and avoid the race condition with building them entirely. You would probably want to keep the key-generating program around somewhere, though. Another option would be to build they keyfile as part of the libopendkim build, outside of the "check" target, storing them in the build directory with the other libopendkim build stuff. Finally, there's this option, mimicking the test-socket stuff that's already there, but doing nothing for #110: diff --git a/configure.ac b/configure.ac
index 828fe53f..649338d6 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2471,6 +2471,19 @@ then
AC_SUBST(TESTSOCKET)
fi
+
+#
+# specify test keyfile
+#
+AC_ARG_WITH([test-keys],
+ AS_HELP_STRING([--with-test-keys],
+ [writable file path for temporary test keys]),
+ [testkeys="$withval"], [testkeys="./testkeys"])
+TEST_KEYS=$testkeys
+AC_DEFINE_UNQUOTED([TEST_KEYS],
+ "${TEST_KEYS}",
+ [writable file path for temporary test keys])
+
#
# Platform Specific Configuration
#
diff --git a/libopendkim/tests/t-testdata.h b/libopendkim/tests/t-testdata.h
index 1fd481c5..95dfcaf7 100644
--- a/libopendkim/tests/t-testdata.h
+++ b/libopendkim/tests/t-testdata.h
@@ -5,6 +5,7 @@
** Copyright (c) 2009-2012, The Trusted Domain Project. All rights reserved.
*/
+#include "build-config.h"
#define CRLF "\r\n"
#define SP " "
@@ -12,7 +13,7 @@
#define LARGEBODYSIZE 65536
#define LARGELINESIZE 4100
-#define KEYFILE "/tmp/testkeys"
+#define KEYFILE TEST_KEYS
#define JOBID "testing"
#define SELECTOR "test"I'm not 100% sure that |
In https://github.com/trusteddomainproject/OpenDKIM/blob/develop/libopendkim/tests/t-testdata.h#L15 a fixed path under
/tmpis used for the test keys.This is not a huge vulnerability, but it is a silly one since it is so well-known and easy to avoid: https://owasp.org/www-community/vulnerabilities/Insecure_Temporary_File
Either a random name should be chosen securely, or perhaps the temporary keys should be created within the build directory.
The text was updated successfully, but these errors were encountered: