"Trustworthy Whole-System Provenance for the Linux Kernel" - usenix.org/system/files/confer

> .. We present Linux Provenance Modules (LPM), the first general framework for the development of provenance-aware systems. We demonstrate that LPM creates a trusted provenance-aware execution environment, collecting complete whole-system provenance while imposing as little as 2.7% performance overhead on normal system operation...

Regarding "How Ledger Hacked an HSM" - cryptosense.com/blog/how-ledge - I have doubts about the significance of this if they are correct in speculating that this is associated with SafeNet's recent Sentinel advisory. Sentinel is SafeNet's software licensing/DRM thingy... quite separate to their actual HSM business... but maybe I'm missing something

"Understanding Real-World Concurrency Bugs in Go" - songlh.github.io/paper/go-stud

"..we perform the first systematic study on concurrency bugs in real Go programs. We studied six popular Go software including Docker, Kubernetes, and gRPC. We analyzed 171 concurrency bugs in total, with more than half of them caused by non-traditional, Go-specific problems. ... we also studied their fixes, performed experiments to reproduce them, and evaluated them with two publicly-available Go bug detectors.

""Sibyl - A Miasm2 based function divination"" - github.com/cea-sec/Sibyl

"In reverse engineer work.. Tools have been developed to automate.. Some are based on CFG.. signature (Bindiff), others on magic constants (FindCrypt) or enhanced pattern matching (FLIRT). Sibyl is one of these tools, dynamic analysis oriented and based on Miasm2 (github.com/cea-sec/miasm). The idea is to identify functions from their side effects. That way, identification is independent of the used implementation."

"Assessing Unikernel Security" - nccgroup.trust/globalassets/ou

"We surveyed two major unikernels, Rumprun and IncludeOS .. Features like ASLR, W^X, stack canaries,
heap integrity checks and more are either completely absent or seriously flawed. If an
application running on such a system contains a memory corruption vulnerability, it is
often possible for attackers to gain code execution, even in cases where the application’s source and binary are unknown ..

Finally replaced the cracked screen in my phone and its almost completely inoperable charge port. Took me a couple of hours... it's the 3rd screen. I try to make phones last a few years...

Anyway my laptop screen also died

I just can't have devices, they all fail

@projectgus enthusiastic consultants: yes, definitely a thing! We can't SCRUMgile all our problems away.. I might be misinterpreting but there seems to be a pervasive premise that developers are fungible, perhaps in some markets for some projects that works but it's far from true in more challenging contexts - at the very least, effectively applying individuals IMHO means considering their unique capabilities (& weaknesses) in the team. I've read some of bcantrill's stuff but not enough :)

@projectgus FWIW it's certainly possible to have tech debt city *and* disgusting waste on nothing stakeholders care about, I'd never have believed the amount of code that can be written which had no business being written until I'd seen it myself..

I shouldn't have made my rant about scrum.

Perhaps it's just my career path atm, but I find there's often surprise around poor security outcomes, but when we add up lack of explicit seceng goals/investments it should really be opposite of surprising

Honestly the scrum guide reads like some kind of cult

It assumes the Product Owner knows best, and everyone Shall Respect the Product Owner

Clearly then the single most impactful thing you can do for an organization's security program isn't tools or training, it's to ensure product owners understand their security goals and how to achieve them when faced with the various dysfunctions unique to their environment

Show thread

.. I know this is obvious/boring, but there's others who should know better on birdsite & it wasn't always obvious to me: the front of my career was a mix of small/large orgs but always in small teams, often as the lone coder, personally accountable but always empowered

Maybe I'm just unlucky, but scrumgile seems to create pathological 1-way relationships w/product owners & devs who cope via learned helplessness, desensitized to issues they could fix if only owners would put them on the backlog

Show thread

.. there's a staggering amount of hubris among hackers who've never built stuff. Including myself as an engineer: I didn't "get" how dominant the shape of an org, its people systems, feedback loops (or lack thereof), commercial settings etc were until I spent a few years exposed to management/inter-BU/customer things on larger teams.

In a fight between a smug infosec rockstar vs 87 sprints under a tunnel-visioned SCRUMlord, yrs of 0% slack time & career-driven-development, I know who I'd bet on

Show thread

Training, tools, even competent engineers are no match for perverse incentives. Infosec is still quick to bash engineers based on flaws in products & assume they don't "get" offense. I too once thought the fix belonged with engineers, maybe training, but let me tell you something: top ~10-20% of devs I've worked with already know how to attack their product, know enough to be training their peers, & given ~months to re-train would easily make better offsec hackers than most that spent ~years..

@0xf0 @szbalint In .au there's a not-quite-high-frequency (5-min interval) electricity trading [1], with a floor & ceiling price. This is how Tesla was able to install a giant battery plant [2] in South Australia that paid for itself in months, out-maneuvering the gas generators who have 20-30min response times while still saving the state 10s of millions. "Simple supply & demand"... not normally an Elon fanboi but this was a cool story

[1] eex.gov.au/large-energy-users/

[2] afr.com/business/energy/solar-

@Kensan @cynicalsecurity awesome stuff, thanks for the link!

Xen certainly is showing its age, it's just... amazingly hackable. Like the perl of hypervisors :-) I guess that's why still so many experiments are still being done with it. I'm just skeptical that Linux/kvm is much of a step forward in attack-surface/complexity.

@Kensan @cynicalsecurity (on x86 at least, I think: I assume you could both point me to earlier PV shenanigans than Xen :D) I've not been reading many papers about virtualization for the last year, but I'm still waiting for treatments of KVM equivalent to really awesome papers like this: trustkernel.com/uploads/pubs/n "Deonstructing Xen", where they analyze flaw history, attack surface, architecture and logically put it back together again... Linux/KVM is a far more difficult monolith

@Kensan @cynicalsecurity This has always profoundly offended me! This is why I've been such a xen head over the years; partly because it was always there, but also partly because we can boil away that crud if we want. I might be exposing my ignorance here, I'm burning out in a very reactionary/response-driven job atm and can't plan research time like I used to, but I still wonder what's so revolutionary about Firecracker other than being a modern take on PV/cruftless-boot that xen pioneered

@cynicalsecurity @Kensan anyway thanks for allowing me to indulge in this cathartic thread :D I will try to post about things that matter one day

@cynicalsecurity @Kensan If I'm honest I can't remember a paid gig where that wasn't the case; what seems to be accelerating the entropy is fewer folks (me included) understanding layers immediately adjacent to or within their scope of work. Just recently saw in a moderately famous codebase w/code-review process, in an area configuring networking, it shells out to `cat /proc/.. | cut -f2 -d' '` instead of calling uname(), in compiled userland code that has no business doing that in 1st place

@cynicalsecurity @Kensan a colleague on the most memorable of these once described the whole thing as "a very expensive experiment we didn't need to do"

@cynicalsecurity @Kensan I guess I want to describe the producer/consumer things that these setups were serving and how their view of the world was supposed to be ignorant of how multi-site worked, but you're right it really was just a clusterfsck and describing it as a distributed system actually obscures the crimes the creators of those systems did to otherwise perfectly innocent 1s & 0s, even if the cascading stability & reliability issues were fascinating to me at the time

Show older
Mastodon

Server run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!