A CVE for exeCVE()
Local privilege escalation via execve()
71–80 of 116 posts
Re: Local privilege escalation via execve()
#72Earlier quoted context omitted.
Plenty, Microsoft has security teams whose job is to attack Windows. Naturally they don't do blog posts about what they find.
You talk as if Windows is the only OS that has red teams attacking the system when clearly that isn’t even remotely true.
I talk about that because it is public, and the OP mentioned Windows.
It he talked about Android, I would have mentioned Project Zero.
Don't twist the meaning of posts.
Re: Local privilege escalation via execve()
#73Earlier quoted context omitted.
Stability of ecosystem. No systemd. Native ZFS. Jails over Docker. Been using it for 20+ years and it’s my preferred server OS.
No, I mean do you run FreeBSD boxes where users who should not ever assume root access actually login to do tasks? My point is that if you do, you probably shouldn't run, for e.g applications which need production db credential, or hold sensitive data on these boxes, or .. whatever. Edit: I use FreeBSD extensively, for various things -- but shell access to them is restricted to the sysadmins..
Hard to tell about FreeBSD, it's basically extincted, but think of webhosting servers, wordpress, cPanel/Plesk and alike.
often it's ssh'able with things like rbash and other restrictions and almost always you, well, can run something there (as you can edit php/other files right from web management ui).
Hordes of this (in Linux world).
Re: Local privilege escalation via execve()
#74> IV. Workaround > No workaround is available. Oh dear.
Does this vulnerability not rely on SUID binaries?
Nope. Try the PoC on macOS:
https://github.com/califio/publications/blob/main/MADBugs/fr...
The script downloads and sets up FreeBSD on QEMU, then runs the exploit.
The exploit is very smart: https://github.com/califio/publications/blob/main/MADBugs/fr.... It basically backdoors sshd.
Re: Local privilege escalation via execve()
#75- args->endp - args->begin_argv + consume); + args->endp - (args->begin_argv + consume)); tbh I've considered simply banning math-operator-precedence in projects I work on, and requiring all mixed-operator code to use parenthesis or split to multiple statements. I do that myself, at least. I've seen so many mistakes from it, and seen people spend so much pointless and avoidable time deciphering and verifying it, it r…
I think I’d generalize that rule to require parentheses in any situation where adding parentheses could change the interpretation. I think that’d leave int addition and multiplication, and I don’t think there’s anything else offhand. Other than those, require parentheses.
a - b - c
Re: Local privilege escalation via execve()
#76- args->endp - args->begin_argv + consume); + args->endp - (args->begin_argv + consume)); tbh I've considered simply banning math-operator-precedence in projects I work on, and requiring all mixed-operator code to use parenthesis or split to multiple statements. I do that myself, at least. I've seen so many mistakes from it, and seen people spend so much pointless and avoidable time deciphering and verifying it, it r…
I think I’d generalize that rule to require parentheses in any situation where adding parentheses could change the interpretation. I think that’d leave int addition and multiplication, and I don’t think there’s anything else offhand. Other than those, require parentheses. a - b - c is order dependent, even if its deterministic and knowable. When I’m scanning the code to look for a pesky bug, I don’t wanna have to tak…
> I think that’d leave int addition and multiplication, and I don’t think there’s anything else offhand. Other than those, require parentheses.
At this point you just require every compound infix expression to be parenthesised, the terseness isn't worth the inconsistency. Especially as, as others have noted, these operations are only associative when working in some classes (notably not necessarily when dealing with floats).
And then you do automatic parens insertion in the LSP, so you write
a - b - c
(a - b) - cRe: Local privilege escalation via execve()
#77- args->endp - args->begin_argv + consume); + args->endp - (args->begin_argv + consume)); tbh I've considered simply banning math-operator-precedence in projects I work on, and requiring all mixed-operator code to use parenthesis or split to multiple statements. I do that myself, at least. I've seen so many mistakes from it, and seen people spend so much pointless and avoidable time deciphering and verifying it, it r…
Smalltalk didn't have math operator precedence, and I thought it was very annoying but I've come to believe it was a good idea.
Re: Local privilege escalation via execve()
#78- args->endp - args->begin_argv + consume); + args->endp - (args->begin_argv + consume)); tbh I've considered simply banning math-operator-precedence in projects I work on, and requiring all mixed-operator code to use parenthesis or split to multiple statements. I do that myself, at least. I've seen so many mistakes from it, and seen people spend so much pointless and avoidable time deciphering and verifying it, it r…
IIRC several industry and government coding standards don't permit evaluations in arguments to functions, as the compiler can end up doing wonky things, to say nothing of the likely human error. These are the kind of standards we should be adapting into a software building code to avoid security holes like this one.
Re: Local privilege escalation via execve()
#79Earlier quoted context omitted.
If you think Linux is on their first or second, I'm not sure how or what you're counting.
> I'm not sure how or what you're counting. The recent two. FailCopy and DirtyFrag and FreeBSD with Execve. 2 - Linux 1 - FreeBSD. Of course, all OS have had past-time exploits. Three now have made the news.
> 2 Linux
Three. I don't know if this has a name yet... https://news.ycombinator.com/item?id=48067734
Re: Local privilege escalation via execve()
#80[flagged]