Another reason is that the official Firefox builds for at least GNU/Linux doesn't employ standard exploit mitigations (stack canaries, position independent code, read-only GOT).
One of those groups is Global Cyber Allience (GCA):
"GCA, a 501(c)3, was founded in September 2015 by the Manhattan District Attorney’s Office, the City of London Police and the Center for Internet Security."
> Quicklisp is de-facto the only widely used library manager in Common Lisp world, and so it’s written in Common Lisp and doesn’t have any tests. It’s a wonder for me how it’s not breaking!
Quicklisp also downloads and executes code over plain HTTP with no integrity checks whatsoever.
> In case of Maven - and likely most others - packages are not even digitally signed by the publisher
Last time I explored the atrocious state of language-specific package managers, Maven Central was (and I'm guessing still is) the only language repo that requires that packages are signed [1][2].
Now, whether package signatures are verified on retrieval is another question... (they are not, unless you use a plugin such as pgpverify-maven-plugin [3]).
Obviously anybody with the private key can still introduce malicious code even if you verify your package signatures, but at least it's better than allowing any oppressive regime with a root CA trusted by Mozilla/Microsoft to MITM rust/python/npm/ruby/whatever packages downloaded by its residents.
Had a quick glance and your code is littered with unchecked function calls and potential overflows.
Also: Cookie:../../../<filename>
Where <filename> is a file starting with a value that's interpreted as a valid uid by atoi(). You're saved by a NULL pointer deref when the unchecked getpwuid() fails if the resulting uid is >0 but invalid (unless you're running it on a system where NULL is mapped to readable memory).
> What is the boundary, in digital devices, between hardware and software? It follows from the definitions. Software is the operational part of a device that can be copied and changed in a computer; hardware is the operational part that can't be. This is the right way to make the distinction because it relates to the practical consequences.
> There is a gray area between hardware and software that contains firmware that can be upgraded or replaced, but is not meant ever to be upgraded or replaced once the product is sold.
how does debian developers independently building on their machines help? if anything it adds another point of failure. if you trust upstream enough to run their code, you implicitly trust the state of their hardware anyway (since nobody has the time to completely grasp any reasonably large codebase in its entirety); so it seems sensible to trust their builds more than some random debian maintainer
"For instance, when a maintainer uploads a (portable) source packages with binaries for the i386 architecture, it will be built for each of the other architectures, amounting to 11 more builds."https://www.debian.org/doc/manuals/developers-reference/pkgs...
there was a paper published 2008 on the state of linux/bsd package managers. some of the information is outdated (eg. pacman now signs their packages) however it is probably still of interest, esp. with all the language-specific package managers bent on repeating the security fuckups of the 90s/00s
not necessarily. there are software emulation -- examples would be W^X on OpenBSD[1] and Grsecurity/PaX on linux[2]. Ubuntu[3] and RedHat[4] also has (partial) NX-emulation thanks to ExecShield.
As for OpenBSD and Linux without grsec/pax, one can bypass NX (whether the CPU has the NX-bit or not) by marking the region with the shellcode as executable, eg:
mprotect(shellcode & -pagesize, len, PROT_EXEC);
((void()()) shellcode)();
in an exploit this could be accomplished by ROPing
> FreeBSD lacks basic low-level exploit mitigation, such as Address Space Layout Randomization (ASLR)
the whitepaper you linked was published in 2014 by Shawn Webb, one of the people behind the hardenedbsd fork. that same year a submission for review was opened on phabricator[1] re. merging their aslr work in mainline fbsd.
it was closed on 2015-10-19:
> Closing this revision. FreeBSD is free to pull from HardenedBSD.
another aslr review request was then created on 2016-03-10 by Konstantin Belousov[2]:
> This revision needs review, but there are no reviewers specified.
that same day he sent a call for testing to freebsd-arch[3].
there is also a bugzilla ticket[4] for the people waiting for freebsd to catch up with 2001.
why not freebsd? the freebsd project seem to focus exclusively on post-attack with jails and trustedbsd mac. fbsd has not implemented any of the modern exploit mitigation techniques. i mean, even os x has had full aslr since 2012 lol.
some years ago fbsd was forked to hardenedbsd which has aslr, mprotect restrictions, non-exec pages on cpus w/o NX, randomized lib loading order, etc. i guess the freebsd project is too busy fighting meritocracy cus none of it has been merged as far as i can tell.
as for linux, plenty has been written on linus' stance on what he considers to be a "security circus"; and the mantra on lkml is still that "a bug is a bug". just watch oss-sec and see distro people wading through kernel commit logs (hyperbole) cus sec-related bugs usually aren't reported downstream
stability /or/ security? because a box running code with bugs that may result in a thwarted control flow is the pinnacle of stability?
your firewall won't help against socket re-use; and most configs won't stop connect-backs since they allow unfiltered outbound access to quite a few destination ports