>>902529
I looked at a couple of those papers because I thought maybe it would be about solving actual problems, or just copying how Multics and VMS did it, but it's more UNIX and C bullshit. Multics in the 60s was better than UNIX in 2018.
http://langsec.org/papers/Bratus.pdf
>What unites the printf ’s handling of the format string argument and an imple-
>mentation of malloc?
They're both bugs caused by C bullshit that wouldn't happen if you used a different language.
>The “weird instruction” primitives they supply to exploits.
>This strange conf luence is explained in “Advanced Doug Lea’s malloc Exploits” [5],
>which follows the evolution of the format string-based “4-bytes-write-anything-
>anywhere” primitive in “Advances in Format String Exploitation” [14] to the
>malloc-based “almost arbitrary 4 bytes mirrored overwrite,” for which the authors
>adopted a special “weird assembly” mnemonic,
>aa4bmo .
In the time it took to turn bugs into a “weird assembly” language, they could have done a whole bunch of things, like building a Lisp machine.
>Such primitives enable the writing of complex programs, as explained by Gerardo
>Richarte’s “About Exploits Writing” [13]; Haroon Meer’s “The(Nearly) Complete
>History of Memory Corruption” [8] gives a (nearly) complete timeline of memory
>corruption bugs used in exploitation.
Do you know what's funny about all this? That “weird assembly” language is probably a better programming language than C.
If there's one thing which truly pisses me off, it is the
attempt to pretend that there is anything vaguely "academic"
about this stuff. I mean, can you think of anything closer
to hell on earth than a "conference" full of unix geeks
presenting their oh-so-rigourous "papers" on, say, "SMURFY:
An automatic cron-driven fsck-daemon"?
I don't see how being "professional" can help anything;
anybody with a vaguely professional (ie non-twinkie-addled)
attitude to producing robust software knows the emperor has
no clothes. The problem is a generation of swine -- both
programmers and marketeers -- whose comparative view of unix
comes from the vale of MS-DOS and who are particularly
susceptible to the superficial dogma of the unix cult.
(They actually rather remind me of typical hyper-reactionary
Soviet emigres.)
These people are seemingly -incapable- of even believing
that not only is better possible, but that better could have
once existed in the world before driven out by worse. Well,
perhaps they acknowledge that there might be room for some
incidental clean-ups, but nothing that the boys at Bell Labs
or Sun aren't about to deal with using C++ or Plan-9, or,
alternately, that the sacred Founding Fathers hadn't
expressed more perfectly in the original V7 writ (if only we
paid more heed to the true, original strains of the unix
creed!)
In particular, I would like to see such an article
separate, as much as possible, the fundamental design
flaws of Unix from the more incidental implementation
bugs.
My perspective on this matter, and my "reading" of the
material which is the subject of this list, is that the two
are inseparable. The "fundamental design flaw" of unix is
an -attitude-, and attitude that says that 70% is good
enough, that robustness is no virtue, that millions of users
and programmers should be hostage to the convenience or
laziness of a cadre of "systems programmers", that one's
time should be valued at nothing and that one's knowledge
should be regarded as provisional at best and expendable at
a moment's notice.
My view is that flaming about some cretin using a
fixed-sized buffer in some program like "uniq" says just as
much about unix as pointing out that this operating system
of the future has a process scheduler out of the dark ages
or a least-common-denominator filesystem (or IPCs or system
calls or anything else, it -doesn't matter-!)
The incidental -is- fundamental in dissecting unix, much as
it is in any close (say, literary or historical) reading.
Patterns of improbity and venality and outright failure are
revealed to us through any examination of the minutiae of
any implementation, especially when we remember that one
cornerstone of unix pietism is that any task is really no
more than the sum of its individual parts. (Puny tools for
puny users.)