Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Heap-based buffer overflow in Sudo

qualys.com

Post reply on HN
Print view View original

301–310 of 328 posts

Re: Heap-based buffer overflow in Sudo

#301

Post by moistbar »

Sjonny wrote: post #294
gerdesj wrote: post #176

Earlier quoted context omitted.

"All you need to know about sudo and frankly most other pieces of the Linux userspace is that it is undertested" Fair enough but what do you recommend? Me, I try to keep people out of my systems that I don't trust. This particular snag needs local access but I will grant you that my web server or other exposed service might provide a local interface. Instead of throwing your hands up and screaming "crap" you do your…

> Fair enough but what do you recommend? why do you need to have sudo? I'm perfectly fine without it. sudo is maybe useful in the case where others on the system don't need to know the a password to run as someone else (including root) but need to be able to do that anyway. sudo seems to have gotten a big installation bases through ubuntu and everybody thinks it's normal now, but really for me it's not.

sudo doesn't have to grant full root access to everyone in the group. It can be set up such that certain users only have the ability to run specified commands as root, which is handy for orgs where you might have a group of tier 1 techs that you want to be able to run certain scripts (written by tier 2 or 3, of course) that require root, but you don't trust the engineers enough to have root access to everything.

Re: Heap-based buffer overflow in Sudo

#302

Post by jart »

lmm wrote: post #251
jart wrote: post #219

Earlier quoted context omitted.

Use Actually Portable Executable which enables you to compile textbook C programs as unikernels that boot on bare metal, as well as execute natively on all the existing operating systems too (without needing a runtime or interpreter). We've been working hard to democratize ring0 privileges since spectre has made the performance costs of having an operating system too high: https://github.com/jart/cosmopolitan/issues/…

Much of the point of suggesting Mirage was to get away from C - my position is that the correctness costs of C's undefined behaviour (as implemented by real-world C compilers), limited testing support, poor dependency management and so on are too high.

One of my goals with Cosmopolitan is to attract developers who build high-level languages. MirageOS depends on OCaml which depends on C. We need a sturdy foundation at the lowest levels that can enable these visions by helping high-level environments be successful. Cosmopolitan can be that foundation. For example, the codebase has 192 test programs. Much focus has been placed on using the Undefined Behavior Sanitizer and Address Sanitizer to vet everything. My past experience was working on projects like TensorFlow and I started security initiatives like Operation Rosehub which together helped us have the highest performance software infrastructure that's safer too.

Re: Heap-based buffer overflow in Sudo

#303

Post by GoblinSlayer »

brigandish wrote: post #172
arp242 wrote: post #157

Earlier quoted context omitted.

There are tests. Are there enough tests? Maybe not. But people can do in their spare time whatever they want, including writing code without tests.

People can do what they want in their spare time, true, but that it is their spare time does not make the action responsible or irresponsible, nor does it shelter them from responsibility. Not wearing a seatbelt when at work or in your spare time is irresponsible . Writing code, without tests, that others use (and for security at that) is irresponsible .

That's fine, existing software comes first, decent software comes second, sudo is the former. That said, it's a good candidate for riir (safety, right?), but riir happened to grep instead.

Re: Heap-based buffer overflow in Sudo

#304

Post by jart »

hannob wrote: post #270
jart wrote: post #38

Earlier quoted context omitted.

Or just recompile sudo with -fsanitize=address

This guarantees you a local root exploit: https://seclists.org/oss-sec/2016/q1/363

The -fsanitize=address flag is orthogonal to the runtime library. All -fsanitize=address does is each time the compiler uses memory at address x it generates a few extra instructions which check a bit is set at the shadow address ((x >> 3) + 0x7fff8000). I use a simplified runtime intended to support just that in a few hundred lines of code. Overlaps aren't possible since no shadow address can exist outside the range 0x7fff8000 ... 0x100080000000. Even if you use the stock runtime, I'm not convinced local escalation is possible through having the ability to write foo.PID files. I don't understand how that clobbers files like /etc/shadow.

Re: Heap-based buffer overflow in Sudo

#305

Post by toyg »

masklinn wrote: post #299
toyg wrote: post #94

Earlier quoted context omitted.

> Todd Miller is a sharp developer and core OpenBSD contributor. I wonder why OpenBSD wrote their own version. Could it be that, knowing how the sausage is made, they thought it was better to have a salad...?

> I wonder why OpenBSD wrote their own version. Wonder no more: https://flak.tedunangst.com/post/doas > I started working on doas quite some time ago after some personal issues with the default sudo config. The “safe environment” was under constant revision and I regularly found myself unable to run pkg_add or build a flavored port or whatever because the expected variables were being excised from the environment. If…

Lol - now that you quoted it, I actually remember reading this post back then... but at the time I had just assumed sudo was a linuxism they didn’t particularly appreciate (openbsd people can be... petty), I didn’t know one of their core devs was maintaining it.

Re: Heap-based buffer overflow in Sudo

#306

Post by anonymousiam »

acdha wrote: post #209
anonymousiam wrote: post #200

Earlier quoted context omitted.

Does he moonlight for the NSA?

This response is the “must be aliens” of security. If you remotely think this is the case, ask whether one of the top intelligence agencies in the world would be more likely to attract attention to a deep cover operation many, many years in the making or would invest in making sure that the bug was well concealed so nobody else would be able to use it on, say, .gov servers. If you remember Dual EC_DRBG I know which o…

It was meant as a joke. Lighten up.

Having worked with the IC for decades, I'm well aware of what's going on.

Re: Heap-based buffer overflow in Sudo

#307

Post by acdha »

anonymousiam wrote: post #306
acdha wrote: post #209

Earlier quoted context omitted.

This response is the “must be aliens” of security. If you remotely think this is the case, ask whether one of the top intelligence agencies in the world would be more likely to attract attention to a deep cover operation many, many years in the making or would invest in making sure that the bug was well concealed so nobody else would be able to use it on, say, .gov servers. If you remember Dual EC_DRBG I know which o…

It was meant as a joke. Lighten up. Having worked with the IC for decades, I'm well aware of what's going on.

I figured it was a joke but it's about as original as a standup routine complaining about airline food.

Re: Heap-based buffer overflow in Sudo

#308

Post by GoblinSlayer »

ktpsns wrote: post #300
GoblinSlayer wrote: post #297

Earlier quoted context omitted.

I want to start and stop a couple of systemd services remotely. Currently I expose the command with sudo and run it under a remotely connected user. What are other options?

In your case either use plain /sbin/su: https://man7.org/linux/man-pages/man1/su.1.html or login via root. Your use case sounds very sudo-like, thought. Probably stick to sudo.

It's a batch job. Ah, I see it mentions runuser, will check it.

Re: Heap-based buffer overflow in Sudo

#309

Post by roca »

scaramanga wrote: post #241
roca wrote: post #232

Earlier quoted context omitted.

If we're talking about recompiling a handful of SUID programs, why not just manually translate them into Rust or something similar?

Yes, that's probably a good idea. But it comes with costs. Someone has to learn Rust and then convert all of these programs. And it also has the issue that Rust programs are only memory safe if the unsafe keyword is not used anywhere in the program (correct me if wrong?). So it looks like the effort to do such thing, while noble, and valiant, is essentially an experiment with an uncertain pay-off that could turn out…

You can definitely implement sudo and similar tools without writing any new unsafe code.

You will use existing libraries that contain unsafe code, but you should be able to stick to popular well-tested libraries, which means it will be very difficult for an attacker to find a new exploitable bug in those libraries to attack your tools.

Re: Heap-based buffer overflow in Sudo

#310

Post by ben_bai »

comex wrote: post #71
ddevault wrote: post #49

Earlier quoted context omitted.

>But if sudo were written in Rust, it could have the same level of complexity and not be vulnerable. This is not true. Complexity breeds bugs, including security bugs, and memory safety doesn't change that. Your example is a good one - here's another: doas once failed to limit the environment variables which are passed to the child process, which could be used to nefariously influence the program running (e.g. with L…

Incidentally, after inspecting doas for a few minutes, I found two near-vulnerability bugs in it. The first bug lets any user cause doas to read out of bounds of an array, though not in a way that's exploitable. Well, it's arguably a bug in libc. If you run doas with a completely empty argv (argc = 0, so not even an executable name; the two systems I tried, Linux and macOS, both let you do this), getopt will exit wit…

The argv += optind; is a standard pattern. I have never considered argc=0 case to be possible. I need to read some more on this.

As for your second find. It already got fixed: https://marc.info/?l=openbsd-cvs&m=161176698927944&w=2

Post reply on HN