Hacker News Reader

Comment by Graziano_M | Hacker News Reader

Using vanilla GDB is painful. As a bit of a shameless plug I recommend you check out GEF[1]. It's a large python script that extends GDB to make it a lot better to use. Notably it shows a lot of the state automatically every time the inferior stops. It's oriented around reversing and exploit development, but it definitely doesn't have to be used that way.

[1] https://github.com/hugsy/gef

View on HN

I'll also plug pwndbg[1] here. Like Gef it greatly extends the utility of GDB, and is oriented around exploit development.

[1] https://github.com/pwndbg/pwndbg

I'll make a shameless plug here as Pwndbg maintainer - apart from the FEATURES.md file describing features, you can see some of them detailed on those slides: https://docs.google.com/presentation/d/1mDfA_27DtLUkOaTZ8U9k...

It looks really awesome. Thanks.

This anti-pattern is a bit of a red flag for me though:

    bash -c "$(curl -fsSL http://gef.blah.cat/sh)"

It certainly is. I don't install it that way, or recommend it be installed that way, but others do. You can take that up with the project owner :)

I've never understood why this gets so much hate.

You are downloading and running their python script anyway. Why do you trust their software but not their install script?

The fact that it is hosted on http is suboptimal, but it does redirect to an https github page in this case

the difference includes -- a physical computer you use and care about, need to trust, with a lot of setup and your own efforts involved, may be a single-point endpoint with value and/or state, which is by definition vulnerable versus an ephemeral VM or Docker that is repeatedly created and destroyed in moments, has almost no lasting value since a new one is only a minute away, and has no personal value or customization.

For me it is because it normalizes bad practice. There is a reason we have packages and signatures.

It is not as bad as:

    curl something | sh

Where you can detect on the server side that the download goes into a pipe (due to buffering) and serve different versions of the file depending on if you are downloading it or executing it directly, but it is still bad practice.

How is running a script from a downloaded package any better than running a script from a download script?

The script can change any time, and maybe even just for some people without leaving a trace.

Updating a package in a OS distribution repository requires that it is signed, and spread to all the mirrors (it is unlikely that an attacker controls all of them). This makes it more likely to be discovered and hard to do targeted attacks without leaving a trace.

If it does happen that you are compromised using:

    bash -c "$(curl -fsSL http://gef.blah.cat/sh)"

How will you find out afterwards, that this is what happened?

I run local mirrors of everything I use (with snapshots after updating the mirror), so I at least have a history of the software that I ran to do forensics on. I could not do that if I ran scripts directly from the Internet into a shell.

For example: Something suddenly trying to connect to the Internet (or doing DNS lookups) from one of my segregated systems might prompt me to investigate. Even if you are not so "paranoid" as many would call it (I would call it being diligent), you still get the benefit of others being "paranoid".

So making sure (via packages, mirrors and signatures) that we all get the same "version" of software is important for security.

How can you detect that it’s going to a pipe?

The shell reads a command and then executes it. It doesn't buffer the whole script into memory.

https://news.ycombinator.com/item?id=17636032

I love that anti-pattern. It gets people thinking. It’s not like anyone is gonna download that script, find out what the script downloads, and then read every line of the whole project and its dependencies to see if one of them installs a rootkit.

I sorta agree with you but only because it's an http site which allows easy MITM attacks . Otherwise, you're going to be downloading a shell script and executing it. You are trusting your system to a blind executable either way. Same with using pip, choco, rpm, brew, dnf, etc.

Except with dnf you need signed rpms or to have explicitly disabled gpg checks to install unsigned packages from a 'trusted' source. Ie, much harder to MITM.

The directions for manual installation are listed directly after that. The first page of the documentation even explains how to install it directly from the repo. Also, it's funny that "curling to shell" is what crosses the line. As if any of the installation options even approach the risk of appending .gdbinit with over ten thousand lines of unaudited python, especially in a privileged environment like a debugger. Curling to shell is not particularly dangerous than the alternatives.

Reply on news.ycombinator.com