3 ms·

Apparently someone looked into the FreeBSD temacs commentary on the status report on the HN landing page today ... https://www.freebsd.org/news/status/report-2

• aseipp 10y ago
  All Lisp systems basically work in a manner similar to this, by dumping their 'boot image' to disk so it can be loaded and worked with, as an interactive image. Even systems like Smalltalk do similar things. A setup like this is not particularly unusual in concept, although some of the exact specifics may be different than e.g. SBCL. ASLR is also a weak defense by itself as I noted in that FreeBSD thread. Any ASLR-enabled application is, essentially, about 1 infoleak away from being no different than a non-ASLR application. If you want to stop exploits, invest in real mitigation tech, not cheap defenses, and suddenly you won't need to worry about this so much. (Feel free to add randomization on top of working defenses as an extra layer -- just not by itself.) People always hem and haw over how this makes ASLR not work for XYZ, and thus is a 'security nightmare'. But then, very strangely, we still find that it's very possible to write all kinds of exploits that bypass usable ASLR anyway in a variety of applications, with only a single infoleak, coupled with a vulnerability, at only marginally higher work effort. ASLR does not actually eliminate a class of vulnerabilities, it only adds an extra step in the process of exploitation. It can only truly prevent a narrow class of exploits, under very specific constraints. So, it does seem like there's a real security nightmare happening, but it's almost certainly not because random XYZ thing lacked ASLR at compile time. It's because we invest our 'faith' in stop-gap, mostly futile defense mechanisms that are obsoleted without much extra effort, normally.
  • nneonneo 10y ago
    One big thing that ASLR mitigates is non-interactive exploits. In a lot of applications, you can only send a payload once, and can't modify the payload after the fact (for example, vulnerabilities in image file processors). This is a common point of entry, and ASLR makes exploiting the underlying bugs much harder. So I wouldn't call ASLR a weak defense - it closes off a lot of exploitation avenues by itself, and it can make exploiting interactive situations quite a bit harder. Finding that second infoleak bug isn't always quite so trivial.
    • poizan42 10y ago
      I can tell from experience that the Linux implementation of ASLR however is completely worthless. Why? Because the executable you launch itself isn't randomized. The executable must be completely trivial for there to not be enough usable gadgets to defeat ASLR. The Windows implementation is actually better in this regard since executables are randomized as well as libraries. However the randomization is the same for all processes and only changed on boot (because libraries on Windows usually uses relocations rather than PIC so the pages wouldn't be shareable if they were randomized per process), so an infoleak in one process can be used to attack another.
  • 616c 10y ago
    I do get that, as an amateur Lisper. I have played with CCL and SBCL on and off for a while. Ironically, the AUR package I used Clozure Lisp with does not even exist anymore on Arch AUR repos. https://aur.archlinux.org/packages/ccl-bin/?comments=all https://aur.archlinux.org/packages/ccl-bin/?comments=all (That won't work) I get the trade off, but if you read SBCL dev blogs, like PVK, you will recognize really competent programmers and elegant solutions. https://pvk.ca/ https://pvk.ca/ The problem is these gods (I revere them) cannot possibly encode all the hacks and knowledge. They have to code, and the nuances of such "hacks" are internalized by them and forgotten. Ironically, a lot of shit talk on Lisp transpires here, and it is one of the most sophisticated developer-productive tools I have seen, with many laudable features other toolchains brag about. Lisps had them for years. This is not to be an elitist jackass; the cultural shift to obsolence (sadly, my view) is why only diehards know and others avoid implementation details and functionality: we don't use it, so we don't care. Either way, dead code is scary, especially in such scenarios with binary image dumping and bit fiddling hacks. I was ironically aware of such issues with SBCL when I stumbled on Gentoo Hardened list info when people explained how Lisps have trouble in such constrained environments. https://archives.gentoo.org/gentoo-hardened/message/d2fb14f123e7db18dc7fdbd7ba4c74fa https://archives.gentoo.org/gentoo-hardened/message/d2fb14f1... I worry later on such methods leave blobs of weak executable routines and other items of interest to get a foothold once the unsung heroes of now move on. On the other hand, it is painfully obvious to me higher level languages, with or without memory control, allow more flexbility, depth, and alternatives to avoid buffer overflows and other counterpoints made in other threads here. The devil is in details that fly over my head at the speed of light. Life is a tradeoff. The fact that the world uses FreeBSD (WhatsApp) and ASLR is not fully implemented means, yeah, it is complicated. It is scary to me, a guy who shits himself at macros and could not code a rudimentary one-pass compiler if you held a gun to my head.