Skip to content
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

maketempf() assumes /tmp is writable #1273

Open
danieldjewell opened this issue May 21, 2019 · 4 comments

Comments

@danieldjewell
Copy link

commented May 21, 2019

Hello!

Although this is probably a minority of cases, running testssl.sh on a system that does not permit writing to /tmp (e.g. Termux on Android) causes the entire script to fail because the path /tmp is hardcoded and assumed to be writable:

testssl.sh/testssl.sh

Lines 16676 to 16677 in d6fb232

maketempf() {
TEMPDIR=$(mktemp -d /tmp/testssl.XXXXXX) || exit $ERR_FCREATE

A simple fallback to trying to write to the current directory seems like an easy and workable solution? I can write it up and do a PR if you'd like.

@drwetter

This comment has been minimized.

Copy link
Owner

commented May 22, 2019

Hi @danieldjewell ,

sounds good, we could work on that. Just out of curiosity: Did you get testssl.sh to work on Android? I tried a (longer) while back and I didn't get anywhere fast enough.

Cheers, Dirk

@drwetter

This comment has been minimized.

Copy link
Owner

commented May 24, 2019

Daniel: in the case I wasn't answering clear enough: yes, please go ahead if you want to submit a PR.

I am happy to do it as well otherwise.

@danieldjewell

This comment has been minimized.

Copy link
Author

commented May 24, 2019

@drwetter Sounds good! I'll work on it!

Actually, no, the script does not run fully ... there are a few other issues on Termux that I'm going to look at ... the next one is quoted below. The error is that one can't write to /dev/stdout on Termux (not rooted)... I'm not sure if there are other things that are breaking it.

The script does start running on Termux -- it detects OpenSSL, it starts some of the scans, and does output some results. (I'm not 100% sure but I don't believe the deb package of openssl-1.1.1b-3 from termux-packages enables all of the "old" ciphers for testing -- it seems it might not enable SSLv2/3 by default -- see: https://github.com/termux/termux-packages/blob/master/packages/openssl/build.sh for the build options... but that's not too terribly difficult to fix -- I've compiled openssl before directly inside Termux with additional options.)

That said, I'm not too sure if there are additional things that could break. I'll dig in and find out. I see a few ways to possibly address these issues:

  • Write some kind of platform detection into the system and then modify the various things that would break on that platform (e.g. on Termux, $PREFIX and $HOME are set to /data/data/com.termux/files/usr and /data/data/com.termux/files/home, respectively) ... This would be good if there are mutliple platforms that need very custom settings to work (are there others?) ... obviously, this is also somewhat complex to maintain ...
  • Use more of a "test and fallback" approach - this should work for the /tmp issue, but I'm not sure about the /dev/stdout issue... This method could be good in that it might cover more "edge"/"fringe" cases automatically without having to write specific per-platform customizations (like Termux or other somewhat non-standard systems)

You know the code far better than I -- I'm not sure what the best approach is here.

I hope my message doesn't sound too critical ... I do really appreciate the work you've done 😁 (Eine Frage... Ich habe bemerkt, dass Sie in Hamburg wohnen? Sind Sie Deutscher? In diesem Fall verzeihen Sie bitte meine amerikanische umständliche Antwort... 😁 ... Wenn Sie Deutscher sind, kann ich natürlich im "Direktmodus" schreiben/antworten -- Ich mag die deusche Direktheit (und die Direktheit der deutschsprachigen Länder) lieber 😁)

MfG,

-Daniel

san="$(asciihex_to_binary_file "${dercert:j:len1}" "/dev/stdout")"

@drwetter

This comment has been minimized.

Copy link
Owner

commented May 27, 2019

The script does start running on Termux -- it detects OpenSSL, it starts some of the scans, and does output some results. (I'm not 100% sure but I don't believe the deb package of openssl-1.1.1b-3 from termux-packages enables all of the "old" ciphers for testing -- it seems it might not enable SSLv2/3 by default -- see: https://github.com/termux/termux-packages/blob/master/packages/openssl/build.sh for the build options... but that's not too terribly difficult to fix -- I've compiled openssl before directly inside Termux with additional options.)

That's a matter of fine tuning. For the most part, also an openssl 1.1.1 is fine as the critical things are done with network sockets. Actually David and myself were discussing whether we're should use openssl 1.1.1 in the future.

Write some kind of platform detection into the system and then modify the various things that would break on that platform (e.g. on Termux, $PREFIX and $HOME are set to /data/data/com.termux/files/usr and /data/data/com.termux/files/home, respectively) ... This would be good if there are mutliple platforms that need very custom settings to work (are there others?) ... obviously, this is also somewhat complex to maintain ...

Platform detection is not good and I try to avoid it. Think about e.g. BSD's sed: I can't tell whether the user also has GNU's sed installed throw ports, similar to Mac OSX. So what testssl.sh does is testing whther a feature / capability exists and populate global vars for this.

Use more of a "test and fallback" approach - this should work for the /tmp issue, but I'm not sure about the /dev/stdout issue... This method could be good in that it might cover more "edge"/"fringe" cases automatically without having to write specific per-platform customizations (like Termux or other somewhat non-standard systems)

Actually if there are more cases like with stdout it would be better to think about a global approach (see previous comment) instead of hundreds (exaggerating) of small PRs. Because at the moment I don't have a picture what breaks on termux and what's to come. I appreciate if testssl.sh works on more platforms but I would like also to have a good code quality.

If you think it's more to come, you can also just get ~everything to work in your fork and when you think that a part of it is ready, then submit a PR. This part can be a "resolving the tmpfile issue" or "resolving the stdout issue".

hope my message doesn't sound too critical ... I do really appreciate the work you've done (Eine Frage... Ich habe bemerkt, dass Sie in Hamburg wohnen? Sind Sie Deutscher?

Ja. But we should continue in English here as it's the common denominator.

Ich mag die deusche Direktheit (und die Direktheit der deutschsprachigen Länder) lieber

Depends on where you are in the US or other English speaking countries. E.g. New York, especially the city, is not known for polite and indirect waffle. ;-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.