4 ms·

"i wanted to get on the machine where the application gets built and the easiest way to do this would be a postinstall script in package.json, so i did that wit

"i wanted to get on the machine where the application gets built and the easiest way to do this would be a postinstall script in package.json, so i did that with a simple reverse shell payload" Just want to make sure I understand this. They made a hello world app and submitted it to todesktop with a post install script that opened a reverse shell on the todesktop build machine? Maybe I missed it but that shouldn't be possible. Build machine shouldn't have outbound open internet access right?? Didn't see that explained clearly but maybe I'm missing something or misunderstanding.

trallnag 2y ago
Isn't it really common for build machines to have outbound internet access? Millions of developers use GitHub Actions for building artifacts and the public runners definitely have outbound internet access
- arccy 2y ago
  A few decades ago, it was also really common to smoke. Common != good, github actions isn't a true build tool, it's an arbitrary code runtime platform with a few triggers tied to your github.
- tomjakubowski 2y ago
  Indeed, you can indeed punch out from an actions runner. Such a thing is probably against GitHub's ToS, but I've heard from my third cousin twice removed that his friend once ssh'ed out from an action to a bastion host, then used port forwarding to get herself a shell on the runner in order to debug a failing build.
  - gtirloni 2y ago
    So this friend escaped from the ephemeral container VM into the build host which happened to have a private SSH on it that allowed it to connect to a bastion host to... go back to the build host and debug a failed build that should be self-contained inside the container VM which they already had access in the first place by the means of, you know, running a build on it? Interesting.
  - TheDong 2y ago
    > probably against GitHub's ToS, but Why would running code on a github action runner that's built to run code be against ToS? If it was, I'm sure they'd ban the marketplace extensions that make it absolutely trivial to do this: https://github.com/marketplace/actions/debugging-with-ssh https://github.com/marketplace/actions/debugging-with-ssh
    - deleted 2y ago
      [deleted]
  - pulkitsh1234 2y ago
    could have just used https://github.com/mxschmitt/action-tmate https://github.com/mxschmitt/action-tmate
- selfhoster 2y ago
  It is and regardless a few other commenters saying or hinting it isn't...it is. An air gapped build machine wouldn't work for most software built today.
  - fc417fc802 2y ago
    Strange. How do things like Nix work then? The nix builders are network isolated. Most (all?) Gentoo packages can also be built without network access. That seems like it should cover a decent proportion of modern software. Instances where an air gapped build machine doesn't work are examples of developer laziness, not bothering to properly document dependencies.
  - ok_dad 2y ago
    Sounds like a problem with modern software build practices to me.
    - pixl97 2y ago
      Ya too many people think it's a great idea to raw dog your ci/cd on the net and later get newspaper articles written about the data leak. The number of packages that is malicious is high enough, then you have typo packages, and packages that get compromised at a later date. Being isolated from the net with proper monitoring gives a huge heads up when your build system suddenly tries to contact some random site/IP.
      - turtlebits 2y ago
        People don't think it's a great idea. In general, its just too much additional work/process - for very little benefit. You're far more likely to encounter a security issue from adding/upgrading a dependency than your build process requiring internet access.
TheDong 2y ago
In what world do you have a machine which downloads source code to build it, but doesn't have outbound internet access so it can't download source code or build dependencies? Like, effectively the "build machine" here is a locked down docker container that runs "git clone && npm build", right? How do you do either of those activities without outbound network access? And outbound network access is enough on its own to create a reverse shell, even without any open inbound ports. The miss here isn't that the build container had network access, it's that the build container both ran untrusted code, and had access to secrets.
- arccy 2y ago
  It's common, doesn't mean it's secure. A lot of linux distros in their packaging will separate download (allows outbound to fetch dependencies), from build (no outside access). Unfortunately, in some ecosystems, even downloading packages using the native package managers is unsafe because of postinstall scripts or equivalent.
  - zahlman 2y ago
    >Unfortunately, in some ecosystems, even downloading packages using the native package managers is unsafe because of postinstall scripts or equivalent. Funny you should mention this because I was just psyching myself up to submit my blog piece from last night on the topic. In Python, downloading packages using the native package installer (Pip, which really doesn't itself do anything that could be called package management) is unsafe because of build scripts - unless you tell it to only accept pre-built packages, defeating the point of the systems these Linux distros are using. (I assume/hope people in this position are aware of the problem and have rigged up another solution with the API. In the post I commented that I don't know of such solutions being publicly available, but surely they exist somewhere.) You'd be justified in wondering why the build script runs when you only ask to download the package. It's mainly because of the historically atrocious approach to metadata (and all the legacy packages for which installation is still supported). But from reading the issue trackers, it seems like the code paths aren't especially easy to disentangle, either - since they've gone so long with the assumption baked in that the problem isn't really solvable. In other HN posts I've complained about people pointing out things in the Python packaging ecosystem that aren't really problems. But this really is one. https://zahlman.github.io/posts/2025/02/28/python-packaging-3/ https://zahlman.github.io/posts/2025/02/28/python-packaging-...
leni536 2y ago
Note that without a reverse shell you could still leak the secrets in the built artifact itself.

trallnag 2y ago

Isn't it really common for build machines to have outbound internet access? Millions of developers use GitHub Actions for building artifacts and the public runners definitely have outbound internet access

arccy 2y ago
A few decades ago, it was also really common to smoke. Common != good, github actions isn't a true build tool, it's an arbitrary code runtime platform with a few triggers tied to your github.
tomjakubowski 2y ago
Indeed, you can indeed punch out from an actions runner. Such a thing is probably against GitHub's ToS, but I've heard from my third cousin twice removed that his friend once ssh'ed out from an action to a bastion host, then used port forwarding to get herself a shell on the runner in order to debug a failing build.
- gtirloni 2y ago
  So this friend escaped from the ephemeral container VM into the build host which happened to have a private SSH on it that allowed it to connect to a bastion host to... go back to the build host and debug a failed build that should be self-contained inside the container VM which they already had access in the first place by the means of, you know, running a build on it? Interesting.
- TheDong 2y ago
  > probably against GitHub's ToS, but Why would running code on a github action runner that's built to run code be against ToS? If it was, I'm sure they'd ban the marketplace extensions that make it absolutely trivial to do this: https://github.com/marketplace/actions/debugging-with-ssh https://github.com/marketplace/actions/debugging-with-ssh
  - deleted 2y ago
    [deleted]
- pulkitsh1234 2y ago
  could have just used https://github.com/mxschmitt/action-tmate https://github.com/mxschmitt/action-tmate
selfhoster 2y ago
It is and regardless a few other commenters saying or hinting it isn't...it is. An air gapped build machine wouldn't work for most software built today.
- fc417fc802 2y ago
  Strange. How do things like Nix work then? The nix builders are network isolated. Most (all?) Gentoo packages can also be built without network access. That seems like it should cover a decent proportion of modern software. Instances where an air gapped build machine doesn't work are examples of developer laziness, not bothering to properly document dependencies.
- ok_dad 2y ago
  Sounds like a problem with modern software build practices to me.
  - pixl97 2y ago
    Ya too many people think it's a great idea to raw dog your ci/cd on the net and later get newspaper articles written about the data leak. The number of packages that is malicious is high enough, then you have typo packages, and packages that get compromised at a later date. Being isolated from the net with proper monitoring gives a huge heads up when your build system suddenly tries to contact some random site/IP.
    - turtlebits 2y ago
      People don't think it's a great idea. In general, its just too much additional work/process - for very little benefit. You're far more likely to encounter a security issue from adding/upgrading a dependency than your build process requiring internet access.

TheDong 2y ago

In what world do you have a machine which downloads source code to build it, but doesn't have outbound internet access so it can't download source code or build dependencies? Like, effectively the "build machine" here is a locked down docker container that runs "git clone && npm build", right? How do you do either of those activities without outbound network access? And outbound network access is enough on its own to create a reverse shell, even without any open inbound ports. The miss here isn't that the build container had network access, it's that the build container both ran untrusted code, and had access to secrets.

arccy 2y ago
It's common, doesn't mean it's secure. A lot of linux distros in their packaging will separate download (allows outbound to fetch dependencies), from build (no outside access). Unfortunately, in some ecosystems, even downloading packages using the native package managers is unsafe because of postinstall scripts or equivalent.
- zahlman 2y ago
  >Unfortunately, in some ecosystems, even downloading packages using the native package managers is unsafe because of postinstall scripts or equivalent. Funny you should mention this because I was just psyching myself up to submit my blog piece from last night on the topic. In Python, downloading packages using the native package installer (Pip, which really doesn't itself do anything that could be called package management) is unsafe because of build scripts - unless you tell it to only accept pre-built packages, defeating the point of the systems these Linux distros are using. (I assume/hope people in this position are aware of the problem and have rigged up another solution with the API. In the post I commented that I don't know of such solutions being publicly available, but surely they exist somewhere.) You'd be justified in wondering why the build script runs when you only ask to download the package. It's mainly because of the historically atrocious approach to metadata (and all the legacy packages for which installation is still supported). But from reading the issue trackers, it seems like the code paths aren't especially easy to disentangle, either - since they've gone so long with the assumption baked in that the problem isn't really solvable. In other HN posts I've complained about people pointing out things in the Python packaging ecosystem that aren't really problems. But this really is one. https://zahlman.github.io/posts/2025/02/28/python-packaging-3/ https://zahlman.github.io/posts/2025/02/28/python-packaging-...

leni536 2y ago

Note that without a reverse shell you could still leak the secrets in the built artifact itself.