• Hanzito (unregistered)

    is_truth_dead? frist: file_not_found

  • (nodebb)

    of course, Harry prided himself on the completeness of his C implementation, including execv() and the like

    execv() is part of POSIX, and not part of C.

  • Trolly (unregistered)

    Well, I did that in a few weeks including rewriting it at least one time. It's not that complicated even without bison and yak.

  • (nodebb)

    If the school didn't understand the importance of upgrading, I suppose that Jared B. could always have just mapped out the school's IP space, written a program to force the upgrade to the new version, and then executed that over the insecure endpoint. Though on Windows, that's tricky because you can't delete/replace the EXE file of a currently running program or any other files in use by that, so you'd need to use some trick like the MoveFileEx() function with the MOVEFILE_DELAY_UNTIL_REBOOT flag and then force a reboot. Also this would be legally dubious.

    As Steve_The_Cynic mentioned, execv() is not part of ANSI C and doesn't exist on Windows. I suppose one could implement execv() using CreateProcess() and ExitProcess() without too much trouble; but you'd have a lot more trouble implementing fork() on Windows, which doesn't have any native equivalent. Take a look at how Cygwin implemented fork() on Windows, it's absolutely disgusting; and if you're unlucky with DLL load addresses, it can just fail randomly too.

  • Fik of the borg (unregistered)

    When I read "The opposite of meritocracy is ..." I mentally completed "... politcian", where obedience to the shouter at the top is the decisive factor.

  • Officer Johnny Holzkopf (unregistered) in reply to adamantoise

    How about using system() - part of ISO C90 and probably compatible to POSIX.2 - for the RCE implementation?

  • Klimax (unregistered) in reply to adamantoise

    Few corrections/addenums:

    1. Fork-like functionality does exist, but is not exposed by WinAPI. IIRC For some time Cygwin used it.

    2 As for replacing files, you can do it. Just rename file in use and place new file there and then have process restart. (Lock is on handle, not file) There are few exceptions were it is not possible.

  • Hmmmm (unregistered)

    Also keep in mind "kakastocracy" - rule by the poop

  • (nodebb) in reply to adamantoise

    I suppose one could implement execv() using CreateProcess() and ExitProcess() without too much trouble

    It would be surprisingly difficult to get the semantics correct using only those two functions. Sure, the CreateProcess() would start the new program, but following it with ExitProcess() would mean that the parent would see that the child had quit.

    but you'd have a lot more trouble implementing fork() on Windows, which doesn't have any native equivalent

    It does, in fact, but it's in the "core" bottom-level APIs (NtXxxxxx and ZwXxxxxx), the ones meant for use by the subsystem modules. It exists to facilitate the old POSIX subsystem, and was then used by Interix, and now by WSL. The Win32 subsystem, whether for GUI or console, does not use it at all, and isn't designed to have it used "behind its back". fork() is horribly invasive, requiring special behaviour and treatment all over hell and gone, and Win32 doesn't carry that burden. Instead, we carry the burden of fork()'s non-availability in the Win32 API, if we think that's actually a burden. Which I don't.

  • (nodebb)

    I figured out you're talking about UC-Davis. The internet at large doesn't seem to be aware of any security vulnerabilities in UC-Davis. Do you know something most of the world doesn't?

Leave a comment on “RCE As a Feature”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article