HN user
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."
https://www.cityoflondon.police.uk/advice-and-support/cyberc...
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.
[1] https://maven.apache.org/repository/guide-central-repository...
[2] http://central.sonatype.org/pages/working-with-pgp-signature...
The ISP in question is in Turkey, so it should probably be noted that the Turkish government has a root cert trusted by both Mozilla and Microsoft.
https://ccadb-public.secure.force.com/mozilla/IncludedCACert...
https://social.technet.microsoft.com/wiki/contents/articles/...
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.
See http://ps-2.kev009.com/pccbbs/mobiles/7buj19us.txt ^F EC version
it should be noted that nightmare isn't safe for untrusted websites: https://github.com/segmentio/nightmare/issues/1060
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
huh?
"when will we finally throw away binary uploads" https://lists.debian.org/debian-devel/2014/02/msg00622.html
"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
https://isis.poly.edu/~jcappos/papers/cappos_mirror_ccs_08.p...
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
1: http://marc.info/?l=openbsd-misc&m=105056000801065
2: https://pax.grsecurity.net/docs/mprotect.txt
3: https://outflux.net/blog/archives/2009/05/14/nx-emulation-in...
you bet? yet in your previous comment you stated it as a fact
no. did you read the first paragraph?
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.
1: https://reviews.freebsd.org/D473
2: https://reviews.freebsd.org/D5603
3: https://lists.freebsd.org/pipermail/freebsd-arch/2016-March/...
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
...and could software deployed to the device by some random who just exploited some well-known security flaw that never got patched, kill people?
using software with known problems in order to avoid potential problems from an upgrade does not seem like a non-bad decision
and what about security updates to the snakeoil they sell, eg. https://bugs.chromium.org/p/project-zero/issues/detail?id=69...
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
It should be noted that "The packages and ports collection does NOT go through the same thorough security audit that is performed on the OpenBSD base system." -- http://www.openbsd.org/faq/faq15.html
That's a half-truth. Ideally they would, but they don't.
vlc 2.2.1 (CVE-2015-5949)
php 5.6.18 (CVE-2016-3142, CVE-2016-3141)
firefox 44.0.2 (CVE-2016-1969, CVE-2016-1977, CVE-2016-2790, CVE-2016-2791, CVE-2016-2792, CVE-2016-2793, CVE-2016-2794, CVE-2016-2795, CVE-2016-2796, CVE-2016-2797, CVE-2016-2798, CVE-2016-2799, CVE-2016-2800, CVE-2016-2801, CVE-2016-2802, CVE-2016-1979, CVE-2016-1950, CVE-2016-1974, CVE-2016-1973, CVE-2016-1970, CVE-2016-1971, CVE-2016-1975, CVE-2016-1976, CVE-2016-1972, CVE-2016-1966, CVE-2016-1968, CVE-2016-1967, CVE-2016-1965, CVE-2016-1964, CVE-2016-1963, CVE-2016-1962, CVE-2016-1961, CVE-2016-1960, CVE-2016-1959, CVE-2016-1958, CVE-2016-1957, CVE-2016-1956, CVE-2016-1955, CVE-2016-1954, CVE-2016-1953, CVE-2016-1952)
Obviously these are cherry-picked and are historically known for their many vulns; but they are also popular enough that one would assume that they'd get special attention.
Depending on ports from -STABLE in a security sensitive environment is a bad idea imo.
Using binaries provided by Mozilla is not a good idea (unless they do things differently with the snaps). They are not hardened in any way; ie. no PIE (rendering ASLR pretty much useless), no stack canaries, no relro, ..., making it a lot easier to exploit any given sec-related bug.
$ hardening-check ./firefox
./firefox:
Position Independent Executable: no, normal executable!
Stack protected: no, not found!
Fortify Source functions: no, only unprotected functions found!
Read-only relocations: no, not found!
Immediate binding: no, not found!
It should also be noted that Firefox is one of the few packages that Canonical keeps aligned with Mozilla releases (even 12.04 LTS has the latest firefox), and:
$ hardening-check /usr/lib/firefox/firefox
/usr/lib/firefox/firefox:
Position Independent Executable: yes
Stack protected: yes
Fortify Source functions: yes (some protected functions found)
Read-only relocations: yes
Immediate binding: yesxombrero depends on webkit. truly minimal? right. oriented towards security? have you not seen how WebKit does security? they wait for dozens of reported vulns before patching/disclosing. nothing that depends on webkit can ever be considered "oriented towards security"