(cc'ing misc instead of tech) On Sat, Nov 24, 2012 at 7:21 PM, William Ahern <will...@25thandclement.com> wrote: > On Thu, Nov 22, 2012 at 01:27:46PM -0430, Andres Perera wrote: >> On Thu, Nov 22, 2012 at 11:58 AM, Kevin Chadwick <ma1l1i...@yahoo.co.uk> >> wrote: >> > On Thu, 22 Nov 2012 09:30:41 -0430 >> > Andres Perera wrote: >> > >> >> i'm not sure how using js for configuration files, as opposed to using >> >> a language commonly deployed for the same purpose, such as lua, >> >> presents an innate constraint on security. >> > >> > Firstly the article mentioned JIT preventing true randomisation. >> > >> > Secondly pulling in JS as a dependency even on servers is rediculous and >> > is a language very familiar to attackers and unfamiliar to many users. >> > It would be especially, shall we say kind to attackers utilising rop >> > attacks. >> >> but jit isn't irreparably interleaved with js >> >> am i compromising by running luajit in interpreter mode instead of the >> reference implementation > > Almost certainly, yes. And that's not a slight against Mike Pall's skills. > Complexity is the enemy of security, every time. Merely disabling a feature > doesn't remove its footprint from the code base.
lets make something clear: using luajit as an example does not impose a strict meaning on "disable". consider it an absolute requirement that "disables" entails: not using mmap or mprotect directly, and more importantly, impose memory layout constrictions outside of what system malloc would > > And have you read any of those codebases? The reference Lua implementation > is a model of clear programming, IMO. > >>, moreover, would that imply that lua the language is insecure or is the >> specific implementation at fault? > > Lua-the-language is designed with implementation details in mind. When an > implementation details become intolerably complex, they consider removing > the feature (e.g. the new generational collector in 5.2). i'm not interested in defending the position that having the ability of choosing between two allocators, or even that the allocator is exposed to the user at all, is part of the language. i consider it a stupid argument to participate in. if the intention was to evoke the idea that, in the real world, implementation and design are not conveniently independent, then i would ask for an example that correspondingly uses an implementation detail that is relevant to the light use expected out of a configuration language by a project like polkit >> >> why would the runtime be attractive for rop? what configuration vm >> needs syscalls that would be attractive to an attacker that can change >> the address of a jump? does the runtime really need to open sockets, >> or spawn processes? (i'm not even talking about languages) > > Those syscalls are accessible in the run time environment, whether or not > they're intentionally bound. And that's all that matters, at the end of the > day. If intentions drove run time safety, there would never be attacks > against real-world code. i'm also not interested in perpetually repeating myself, specially when opposing opinions differ on what's lacking in the imaginary, js-driven sudo program. in the same message you quoted i used systrace (no deferred arg-check) as a deterrent. there's no need for overly simplistic quips like "If intentions drove run time safety, there would never be attacks against real-world code"; i don't see how those promote discussion at all
