1. 36
  1. 3

    /tmp/ape

    I hope this isn’t executing some random file out of /tmp if it happens to exist.

    1. 2

      Author here. Here’s the context you didn’t quote. APE first tries to use the ape program off your $PATH. If it isn’t there, then it tries to extract the embedded one to $TMPDIR/ape since it’s defined by POSIX and used by systems like MacOS to create secure user-specific directories. If $TMPDIR isn’t defined, then finally, as a last resort, it extracts to /tmp/ape. This creates a potential race condition where multiple users try to run an APE binary at the same time. So their sysadmin should install the ape program systemwide to fix that.

      1. 1

        I don’t see how this addresses the problem though. Are you saying that it will never use an existing /tmp/ape? If that is the case why use a predictable name instead of something random that doesn’t have the race condition? If it will reuse an existing /tmp/ape then if a malicious user creates a malicious /tmp/ape another user will try to run it.

        1. 2

          That’s a problem with Unix distros rather than APE. The POSIX standard recommendation is to use $TMPDIR. It’s not APE’s responsibility to secure your computer. There’s very little we can do if your distro doesn’t follow standards. We have however always been clear and transparent in documentation. The APE source code has paragraphs talking about this topic. The concern has been raised multiple times on GitHub. If you think there’s something more we could be doing that’s actionable, let me know and I’ll take it into consideration.

          1. 1

            What standard are you talking about? I don’t recall any standard that suggest that it is safe to execute files out of $TMPDIR.

            I would also be interested if you have links to previous discussions or documentation.

            1. 2

              The Open Group Base Specifications Issue 7, 2018 edition IEEE Std 1003.1-2017 (Revision of IEEE Std 1003.1-2008) talks at length in multiple places about TMPDIR and how it addresses concerns about race conditions between multiple users. Concerns about whether or not it’s safe to run programs you’ve downloaded off the internet is a non-technical issue that’s orthogonal to this discussion.

              1. 2

                Just naming a spec isn’t a strong argument. But since apparently I’m bored I decided to grep the version of that spec I could find and only see two notable references to TMPDIR. I don’t know if I have a partial or wrong version.

                Neither of these seem to imply that TMPDIR should be per-user or otherwise safe to execute files from. In fact the second one explicitly says that “Implementations shall ensure that temporary files, when used by the standard utilities, are named so that different utilities or multiple instances of the same utility can operate simultaneously without regard to their working directories, or any other process characteristic other than process ID.” which doesn’t appear to be the case with a static name. Although this is talking more about standard utilities than the properties of the directory itself.

                But even if there was something in the standard I don’t think it is very useful if no one follows it and AFAICT all major distros have a common TMPDIR that is world writable but sticky. So if you are executing a file out of it that you can’t prove that your user wrote you are gonna have a bad time.

                1. 1

                  Neither of these seem to imply that TMPDIR should be per-user

                  Could you explain to me how a multi-user directory defined as an environment variable would work?

                  1. 2

                    Forgive me for misunderstanding the conversation, but my assumption in reading the thread is that the question is actually:

                    why aren’t you using mktemp(1) or similar?

                    1. 1

                      Because ${TMPDIR:-/tmp}/ape.$$ effectively does the same thing except with shell builtins. Fast performance is the most important thing. It then atomically renames the file so there’s no race conditions and you only need to store one copy. Not wasting disk space with a zillion $TMPDIR/ape.9QaW9BO1NB files is very important. It’s not possible to program an executable to delete itself when it’s done running. It’s also not acceptable to have executables delete themselves while they’re running. Maximum transparency is a goal of the project.

                      1. 3

                        $TMPDIR is not guaranteed to be user / process specific, and may be /tmp so the concern is the classic “time of check to time of use” vulnerability. I think that’s a valid concern here.

                        The major problem is that I may not be aware that a program I am using is executed via ape. This means that I might not know to install /usr/bin/ape beforehand leaving me open to exploitation.

                        Also, I’m surprised that you wouldn’t be able to register an atexit that:

                        • forks
                        • setsid
                        • rm argv[0]
                        1. 2

                          We can address your concern by making sure the APE loader is included in Unix distros by default. So far operating systems have had a positive reaction to this new format and have gone to great lengths to help us out. For example, the last two years we spent upstreaming changes to zsh, fish, FreeBSD, and NetBSD are what helped us get this far. Back when I started doing this, there was even a meeting with the POSIX committee (Austin Group) about whether or not the rules against executing shell scripts containing binary code should be lifted, in order to permit formats like this. The answer was yes. So we moved forward. This whole topic of “what if /tmp is compromised by an adversary” never really came up. But then again, back then, the favored approach was to self-modify the binary in place. That approach should address your concerns too. However it made other communities like the NixOS crowd unhappy. So what we’re doing is providing a variety of APE utilities and strategies so you can choose the one that works best for you!

                    2. 1

                      I don’t understand the question.

                      What I meant is that if all users have the same directory in TMPDIR then you have to worry about untrusted files in that directory. If each user had a unique TMPDIR that only they could write to them they can trust it’s contents (to some degree).

        2. 1

          /tmp can also be mounted as noexec in some cases, in which case this may not work. Finding someplace where you are guaranteed to be able to write on every system can be quite difficult (/dev/shm looks like a candidate althought that one I really don’t see why you’d ever want to execute things from), but some XDG env vars might help., e.g. XDG_RUNTIME_DIR if set.

          1. 3

            IIUC the only path that is actually “gaurenteed” to be executable is $HOME/.local/bin as it says “… executable files may be written”. The spec doesn’t say anything specific about exec permissions.

            But $XDG_RUNTIME_DIR does say “The directory MUST be owned by the user, and he MUST be the only one having read and write access to it” which should mitigate the security problems here.

            1. 1

              Would be nice if ape didn’t have to rely on a shell script to start itself, but just execute it directly (I think after you started it at least once it may rewrite itself so it doesn’t have to, but then you lose the “cross OS” portability part).

              1. 1

                Author here. You can make your APE binaries directly executable by “assimilating” them. One of the features of the shell script is a ./foo.com --assimilate flag. It causes your binary to be modified in-place to be ELF or Mach-O depending on the system.

            2. 1

              /tmp can also be mounted as noexec in some cases

              If a system administrator has made that choice, then the APE format is designed to respect their decision by not working around it. What APE binaries do instead is print an error. That way the user can make a decision about whether or not he/she wants to install the ape loader systemwide.

          2. 3

            Under the WSL and Wine section, this page mentions that Microsoft did some kinds of unholy hacks with binfmt_misc to transparently call PE executables on the WSL command line to run them in Windows. I don’t know too much about binfmt_misc, but I’m really curious how this works, and if it’s possible to make it something more standard. I can’t imagine turning that off in WSL for anything — it’s one of my most-used features (and I have no idea how I’d get around it.)

            Can anyone shed some light on how the PE .exe support in WSL works, please? I’d love to read more about it. I’m not really sure how tk RE it myself.

            Two things off the top of my head that I really rely on this compatibility for: xdg-open-wsl (which implements xdg-open through Windows’ associations), and clip.exe which essentially does what xclip does (that is, copy and paste on the Windows clipboard).

            1. 3

              That’s something I’m wondering about too. The entry in /proc/sys/fs/binfmt_misc that seems to be used for Windows doesn’t have any configurable parameters like magic. If I try to define one that has a more specific MZ magic, e.g. 4d5a71467044, then it doesn’t respect that. So it’s probably a bug in the WSL kernel.

            2. 2

              Hey, this is really cool! If anyone cares for a fun reading, I’d like to point you in the direction of ape.s, esp. around lines 536 - 577 and onwards. I haven’t really looked at an embedded loader since the simpler (?) days of MS-DOS. This is actually a really nice way to illustrate that technique, since the way the loader is bootstrapped is, like, really straightforward :D. Also, nice ASCII art!

                1. 1

                  God I hate Markdown 🙄. Thanks!

              1. 1

                Huh, I couldn’t see it - I got redirected to safebrowse.io , because of malware concerns, apparently?

                1. 4

                  Author here. Hopefully you’re not talking about this SafeBrowse? https://www.ibtimes.com/what-safebrowse-google-chrome-extension-secretly-mines-monero-2591635 I’ve also heard similar reports from users of Comcast Xfinity. It’s worth considering upgrading to their business class service, which is fine. You can also fix things by changing your DNS server to 8.8.8.8 or alternatively enabling DNS over HTTP support in Chrome. Google SafeBrowsing has no issues with the justine.lol website. You can even view it if you turn on their maximum enhanced security. Another tip regarding the binaries on the website, you can usually verify their authenticity by going on the VirusTotal website, uploading it, and checking to see if there’s an upvote from “howishexeasier” since that’s me. Anyway good luck and enjoy!

                  1. 4

                    I’m sorry, I was completely off-base. It’s a Comcast thing; it doesn’t even resolve from the cli. That security page came up in Mobile Safari, Safari, & Firefox. My Mac’s dns server is already 8.8.8.8. This is obnoxious! Thanks for the leads.

                    1. 4

                      There’s a haiku in the cosmopolitan codebase for situations like these. https://github.com/jart/cosmopolitan/blob/master/libc/dns/dns.png