Show HN: Credentials dumper for Linux using eBPF • Hacker News Board

Re: Show HN: Credentials dumper for Linux using eBPF

#21

Post by nicce » Tue, Jul 05, 2022, 4:20 PM UTC

mdaverde wrote: post #4

sorcix wrote: post #3

> built as a static binary without any dependencies > As pamspy rely on libpam, we have to set the path where libpam is installed on your distribution. Confusing text in the readme. Does it have dependencies or not?

I read this as, due to pamspy setting an eBPF probe, pamspy needs to know where libpam.so lives. Not that the pamspy needs libpam to be built

It is still quite confusing.

> built as a static binary without any dependencies

Static binaries are explicitly used for removing the need for specific dynamic runtime dependencies. It does not refer to build dependencies, which are not interesting here.

Based on the terms, I would except that libpam is included for the final binary.

Re: Show HN: Credentials dumper for Linux using eBPF

#22

Post by citronneur » Tue, Jul 05, 2022, 4:24 PM UTC

jeff_vader wrote: post #20

Can't you achieve same thing with uprobe[1]? [1]: https://brendangregg.com/blog/2015-06-28/linux-ftrace-uprobe...

You need uretprobe but also need to read an arg by ref so no I don't think so... But thanks for the tip

Re: Show HN: Credentials dumper for Linux using eBPF

#23

Post by yebyen » Tue, Jul 05, 2022, 4:33 PM UTC

pdonis wrote: post #13

So is this an exploit? Or are root privileges on the local machine needed to run it?

I've heard `eBPF` described as "like JavaScript for your kernel" if the kernel itself was being related to a web browser that runs embedded scripts, so, that should give an idea of how much and what type of power it brings, as well as the expected access level to be able to take advantage of it.

Other uses I've seen for eBPF are inspectors that tell what is happening on encrypted connections and the request headers for any connection, including authentication details that you would expect to be protected. It's great to have this kind of capability on systems that you own!

Re: Show HN: Credentials dumper for Linux using eBPF

#24

Post by amelius » Tue, Jul 05, 2022, 4:47 PM UTC

Usecases? What was it conceived for?

Re: Show HN: Credentials dumper for Linux using eBPF

#25

Post by stevenhuang » Tue, Jul 05, 2022, 5:18 PM UTC

nicce wrote: post #21

mdaverde wrote: post #4

Earlier quoted context omitted.

I read this as, due to pamspy setting an eBPF probe, pamspy needs to know where libpam.so lives. Not that the pamspy needs libpam to be built

It is still quite confusing. > built as a static binary without any dependencies Static binaries are explicitly used for removing the need for specific dynamic runtime dependencies. It does not refer to build dependencies, which are not interesting here. Based on the terms, I would except that libpam is included for the final binary.

The entire point of this program is that it hooks the func inside the libpam.so actively being used by the system for auth...

Re: Show HN: Credentials dumper for Linux using eBPF

#26

Post by frellus » Tue, Jul 05, 2022, 5:40 PM UTC

My ignorance, I had no idea eBPF tracing would make grabbing people's passwords so easy .. that's quite scary to me. I thought it was mostly good for telemetry and deep kernel metrics, but this seems like a serious security flaw to me.

Anyone know of any tools to check for abuse?

Re: Show HN: Credentials dumper for Linux using eBPF

#27

Post by AntiRush » Tue, Jul 05, 2022, 5:45 PM UTC

frellus wrote: post #26

My ignorance, I had no idea eBPF tracing would make grabbing people's passwords so easy .. that's quite scary to me. I thought it was mostly good for telemetry and deep kernel metrics, but this seems like a serious security flaw to me. Anyone know of any tools to check for abuse?

Unless you enable unprivileged eBPF, root is required to load a module. If a user has root there are plenty of ways to get passwords.

Re: Show HN: Credentials dumper for Linux using eBPF

#28

Post by freedomben » Tue, Jul 05, 2022, 5:50 PM UTC

nicce wrote: post #21

mdaverde wrote: post #4

Earlier quoted context omitted.

I read this as, due to pamspy setting an eBPF probe, pamspy needs to know where libpam.so lives. Not that the pamspy needs libpam to be built

It is still quite confusing. > built as a static binary without any dependencies Static binaries are explicitly used for removing the need for specific dynamic runtime dependencies. It does not refer to build dependencies, which are not interesting here. Based on the terms, I would except that libpam is included for the final binary.

If libpam was compiled in, then this tool would do nothing. libpam is not a library for this tool, it's a target, like an input file. libpam is a library for the kernel of the target system. this tool hooks into it to do its work.

Re: Show HN: Credentials dumper for Linux using eBPF

#29

Post by NavinF » Tue, Jul 05, 2022, 5:50 PM UTC

staticassertion wrote: post #18

Anyone know what the status is for enforcing signed eBPF programs?

Why? eBPF is usually compiled at runtime (so there’s no binary to sign) and running it inside your kernel requires root.

Re: Show HN: Credentials dumper for Linux using eBPF

#30

Post by mdaverde » Tue, Jul 05, 2022, 5:55 PM UTC

NavinF wrote: post #29

staticassertion wrote: post #18

Anyone know what the status is for enforcing signed eBPF programs?

Why? eBPF is usually compiled at runtime (so there’s no binary to sign) and running it inside your kernel requires root.

Running eBPF programs doesn't necessarily require compilation at runtime nor root privileges. Look into bpftool's skeleton generation as well as CAP_BPF.

With that being said, because eBPF programs can be compiled at runtime, it makes signing eBPF programs trickier. The kernel team doesn't want efforts such as bpftrace to be stifled.

It seems like the conversation on signing eBPF programs is still ongoing with an eye at looking at fsverity to help with the use cases here.