"A survey on formal specification and verification of separation kernels" - https://arxiv.org/pdf/1508.07066.pdf
"... This paper presents an overview of formal specification and verification of separation kernels. We first present the background including the concept of separation kernel and the comparisons among different kernels. Then, we survey the state of the art on this topic since 2000. Finally, we summarize research work by detailed comparison and discussion."
A bunch of the niftiest people are making k07cw/Cult of the Cyber Witch, a new hacker zine complete with regex crossword, and you should definitely check it out https://kultofthecyberw.itch.io/kult-of-the-cyber-witch-issue-1
This year I helped directly invite folks to submit, which resulted in some very interesting talks from people who wouldn't have otherwise submitted. But... struggling a bit with strategy on how to approach different networks this time
I wonder if it's possible to estimate person-hrs that goes into a paper; or estimate total $$$ invested in literature analysing the security of a piece of security-critical software.
The answer is obviously no, unless they cite specific grants
Want to say something about technical debt behind otherwise shiny-looking projects which have had little or no analysis/verification/correctness efforts applied within or outside the project
This should be a quality metric when choosing dependencies
I can't process this Supermicro story yet https://www.bloomberg.com/news/features/2018-10-04/the-big-hack-how-china-used-a-tiny-chip-to-infiltrate-america-s-top-companies
Queue "we told you so!" brigade.. been agonizing over supply-chain issues for years, but that doesn't make this easier for me to process
Timing of "apple kicking SM from their DCs over BMC security issues" rumours ages ago; nasdaq delisting... if this is BS, that's amazing propaganda effort that I also can't process
That's not to say ICS security isn't terrible, or that explosions are impossible, but breathless reporting that ICS vulns = explosions probably need to be considered in context, and the context for regulated/dangerous industries is that it *SHOULD* take multiple problems to make explosions happen..
In the set of conditions that lead to explosion at a gas plant, I may be out of touch (only saw older stuff designed at a time perhaps less trusting of digital systems), but I'd be surprised if modern plants protected them with just "lol ok a single fieldbus sensor value + dumb threshold processed by a single PLC into a single solenoid is good enough here". On the few I saw, it was multiple redundant digital+electronic pathways to detect+trigger shutdowns for anything that could kill/explode.
I know some do, but how many self-proclaimed ICS security researchers have actually spoken to safety engineers that design safety-critical systems, have pitched scenarios at them and found holes in their designs that an ICS vulnerability might exploit? Or have seen control-systems schematics (different to electrical schematic!) of Eg. gas plants where things can explode?
If your interested, please test and let me know how you go!
Todd Mortimer has made significant headway toward reducing the amount of useful ROP gadgets on x86 too. But made especially difficult by polymorphic instructions, x86 being a variable length ISA. ARM64, by comparison, being fixed-length.
I'd highly recommend reading his mailing list post, and commit messages. He's also giving a talk at #EuroBSDCon 2018!
Had an idea that might make an interesting PoC||GTFO submission but seems subject to export control. Luckily it's already written up in a 2009 paper. Related variants already out there but if code is published prior to submission that should satisfy public domain exceptions?
Anyway main point is to educate some netadmins who still seem to think they can skimp on endpoint hardening/monitoring because they've got NSMs etc. But I guess the world already has enough examples of why that's wrong.
"No Security Without Time Protection: We Need a New Hardware-Software Contract" - https://ts.data61.csiro.au/publications/csiro_full_text/Ge_YH_18.pdf
"..requires that operating systems provide time protection, in addition to the established memory protection. We propose OS mechanisms. time protection, and define requirements on the hardware to enable them. We demonstrate that present.. processors do not meet these requirements, making them inherently insecure. We argue the need for a new security-oriented hardware-software contract.."
Listening to Orbital for a bit, re-arranging (personal) computing infra. It occurs to me I don't usually share musical interests: there was a long time where I effectively lived in my own world of random midi/chiptunes/modfiles I found lying around the internet for music, a collection nobody I knew could recognize. So I never really talked about music. Not on purpose; just didn't have a good enough PC for .mp3 for ages, which constrained my listening, and for a long time afterward too.
The #OCaml manual for release 4.07 has apparently received a modest makeover! http://caml.inria.fr/pub/docs/manual-ocaml/index.html
This is obviously reminiscent of ASLR and friends, but I just wish web folks would Just Turn on the Damn Taint Mode They Already Have Already. At least in perl/ruby. I wonder what the set of bugs that taint mode misses but this polyverse thing catches looks like. I also worry about making web folks feeling like they can keep safely doing eval, runtime reflection/"meta-programming" based on user input, etc.
"Introducing Polyscripting the beginning of the end of code injection" - https://blog.polyverse.io/introducing-polyscripting-the-beginning-of-the-end-of-code-injection-fe0c99d6f199
"Polyscripting aims to dethrone code injection [..] by making the central component of code injection impossible
By taking a vulnerable server-side language [..] scrambling the interpreter’s source code as well as your program files, [..] generates a unique instance of that language. A language that behaves and acts just like php but understands and looks like something completely different."
"ASLR PROTECTION FOR STATICALLY LINKED EXECUTABLES" - https://www.leviathansecurity.com/blog/aslr-protection-for-statically-linked-executables
This paper provides insights into the more obscure security weaknesses of statically linked executables, including, but not limited to, the following:
- the glibc initialization code [..]
- what the attack surface looks like [..]
- why mitigations such as RELRO and ASLR are [..] important for statically linked executables
- [..] that static linking disables important security mitigations [..]
Electronics & infosec enthusiast trying to build defendable things. Haskell n00b. Software & systems dev: embedded Linux, data viz, web stuff. I @MakeHackVoid
Follow friends and discover new ones. Publish anything you want: links, pictures, text, video. This server is run by the main developers of the Mastodon project. Everyone is welcome as long as you follow our code of conduct!