37C3 - Writing secure software
Вставка
- Опубліковано 4 січ 2024
- media.ccc.de/v/37c3-11811-wri...
using my blog as example
I have previously given talks about security principles and approaches like Least Privilege, TCB Minimization, and Self Sandboxing. The most frequent feedback has been "I don't know how to apply this in practice". So, in this talk, I will show how I applied those principles in a real-world software project: a CRUD web app. My blog.
I introduced dangerous attack surface on purpose so I could some day give a talk about how to apply these techniques to reduce risk. This is that talk.
I will also introduce the concept of append-only data storage.
The end goal of this talk is to show how much more security you can achieve if you don't take an existing architecture and try to sprinkle security over it, but you make architectural decisions with security in mind.
This is rarely done in practice because there is a fundamental disagreement between security and software engineering. Security is about limiting what can be done with the software, while software engineering is about not limiting what can be done with the software.
My goal with this talk is to show what kind of security gains are possible architecturally. You, too, can sleep soundly at night. Even if the software is written in C. Even if you have bad ACLs or a buffer overflow in the software.
Fefe
events.ccc.de/congress/2023/h...
#37c3 #Security
So fefe is keeping his tiny application more or less secure, but what do I do with those behemoths of hundreds of megabytes of compressed java code that people want to use?
Is it even possible to fulfill these needs with tiny more or less secure applications?
The situation reminds me a bit of those proofs of program correctness. Who can afford these for non tiny programs except for some extraordinary projects?
The hole point of the talk seems to be that feature creep and behemoth bloated software full of unnecessary dependencies are a security anti-pattern for a good reason. Architects and the guys making the decisions on the glf course would do good to remember that. The approach should be avoided to begin with. What to do after you're saddled with this, I don't know and Fefe didn't answer/mention his opinions on that. TCB minimization (and many other principles of secure software development btw) is literally about avoiding that to begin with. To fix it post-hoc is absurdly expensive.
Don't use Java.... go back to bash 😂
Ever since importing * was acceptable, security was out the window.
Use exactly what you actually need.
" but what do I do with those behemoths of hundreds of megabytes of compressed java code that people want to use?" See also Springboot and dozens of automatic dependencies included. :( Just to build an API that massages data a bit.
Don't add security - remove insecurity.
The strategy here is Principle Of Least Privilege + isolation by default, which is the first step in the path to Capability Theory. The talk mentions Sandstorm, which is a pretty solid capability system, the security model exposed to applications in sandstorm is a lot more powerful than what POSIX exposes
This is mostly out of curiosity, and btw I haven't watched the talk just yet so keep that in mind, but I have a question: are you thinking primarily about compile-time capabilities (guaranteed by the type checker) or runtime ones (managed by the kernel, the OS or the 'environment' in general)?
@@mskiptr The more you can pile on the better, but in the context of isolating components of a web server to prevent exploits from doing anything serious, you want the latter. The attacker doesn't generally need to obey your type system, modulo fully-abstract compilers and verified hardware; but they are going to have a hard time breaking out of process isolation.
There is also a third class of capability systems; those mediated by unguessability, and they can be useful for implementing authorisation in webservers. The talk discusses using public key cryptography, which is an example of this class, though it is a slightly weaker model called "capabilities as keys" in that use case.
Loved this talk, his sarcasm is amazing! lol
"Threat modeling sounds like a dirty word, like there's effort involved." I've had lots of fun with dev teams, teaching them about threat modeling and doing guided sessions with them... Even the cynical team members eventually join in and start seeing the fun in the process.
Just a side node. From a security perspective there's no user input. There's only hacker input
😂
I, too, knew what company the "Password Management" bit was about before he said it. I can't believe they're still in business after all their f-ups.
Dear comment section: take this talk with a bit more humor.
There was an open source project mentioned which is about running open source projects securely. What was the name ? I can’t find it.
Perhaps it's qubes? It's a segregated o/s, not sure if that's what he was talking about
Seems like the "What does the industry do" slides were mainly added, so Fefe could have a quick laugh between slides :)
The irony: generating static HTML is "cool" again.
Serving static content via a well-proven minimalist web server should be as secure as it gets, and even if an attacker gets in, there is pretty much only static content.
The point of the talk is to keep your stack/software as lean as possible for what your software has to archive, but then he "bloats" it with a dynamic architecture and LDAP.
However, most of the points are still valid.
that's the joke - they add LDAP for the express purpose of having a pointless attack surface to talk about securing. it's meant to be tongue-in-cheek.
My approach to writing secure software would be the total opposite. Use as much open source software as possible that is already used and maintained. Refrain from rewriting anything that has been already done and is audited by the open source community. Like a webserver, an ldap server. The probability that you forget something in your own "threat model" when you do this on your own is far more likely than something that is already battle-tested. This way you only get more obscurity, not security.
Second, having a modular approach is more maintainable. What if the developer that knows this very hand-crafted specific architecture is gone? What if a quick fix is needed, that would be easily available by updating a dependency, but here you have the responsibility in-house. Do you always want that responsibility? And then you need a new feature and you think you just give the process a tiny bit more permission and suddenly a big hole at the other end of the threat model opens.
If you want to do that, I would much rather spend the time on applying the "threat model" to an existing open source package and by that even give back something to the community.
So... basically you would rather trust strangers than yourself...
Strangers that you know NOTHING of and you have absolutely no idea if they're happening to be foaming at the mouth and on the verge of snapping due to a bug in their brain chemistry.
See: The Moq Library Debacle.
But hey: trust strangers. I'm sure that "The Community" of Blackhats, CIA and Mossad have already reviewed their code vigorously and they know all the 0-days, so you don't have to.
PS: Oh and I'm sure you do Reproducible Builds as well, so you're not susceptible to package manager build-time attack vectors. Right? RIIIIIGHT?
Fefe has dangerous high self confidence
Actually, I would say this approach will tend to be more modular and readable than the enterprise Java programs I've worked with. Anyone here tried to trace the flow of control through a SpringBoot-based program? What about Jackson (de)serialization? There are plenty of gotchas in both that are far less obvious than this approach because tracing the actual program in those cases is infeasible.
You’re spot on
not to mention making everything dependent on you is great for your colleagues if you ever decide to leave. i've had people like this on their way out when i joined companies and they leave behind piles of undocumented systems, often half overdesigned and half rushed (when they lost interest). they also get bored easily, so they use software with a degree of complexity absolutely not required for a solution. and the reimplementations of abandoned services in esoteric languages... that'd include C for most shops by now, but I've seen deno, scala, rust in a java shop, elixir... just mostly good technologies someone used their work time to learn, but nobody else will ever know how to fix.
I do it manually. yes super scalable. that's why industry does some other stuff
So what you do first. Is you write it down. Then you set that on fire. Now with recent development's people can retrieve back information for ash. So next we are going to get the ash and place it in a blender with about 7ml of vinegar. (We wont use something stronger as you may want a margarita after. ) Turn it on and blend into a mush. Now we want to make sure that no one can retrieve this in the future either, and we don't know how advancements will go. So get 10 cans of tuna. Place into large bowl and mix ash/vinegar mulch. Stir vigorously. Now bring said mixture to your local cattery. Give as treat.
And this is how I ended up on a watchlist.
I personally didn't like this talk.
1. Password Manager was hacked => Ha ha, use SSH keys. Well, until every website in exists allows for login with my ssh keypair I think you'll have to stick with using passwords (and therefore, a password manager).
2. Writing anything yourself actually isn't the smartest solution. Of course, bloatware and unnecessary software should be avoided, but in general I'd say that there is a good chance that the popular, open-source solution with code audits is more secure than the thing you hacked together. And that's not to criticise your skill in any way, but just because you wrote it yourself (and therefore you know of no vulnerabilities) doesn't mean that it doesn't have any.
3. Your example is a bit far away from the reality of software development. Sure, we should always think about minimising attack surface etc., but I feel like there is no bigger takeaway than this in your talk.
4. I personally didn't like your style of presenting. You spoke with such high confidence that it seemed condescending to me, especially when you put "the industry doing hilarious, dumb things" and you "being smart, doing everything yourself" that much in contrast.
I'd be really happy to see another security talk from you, but please be more constructive next time and give advice which can actually be generalized.
1. Well do you really need some online password manager? There are plenty of options for something that doesnt autofill them in for you. I have one that works offline, stores an encrypted file on my pc, encrypted with a very safe and long master password i remembered. This file is also backed up several times in several locations, but not in the cloud.
I think its a though argument to make: I need passwords? I need a password manager like last pass.
2. Thats just exactly what he said dude.
3. Considering that was the main point of the talk, i guess it worked out. He even says several times that even if its only a small contribution to security you should do it and that thats better then doing nothing.
4. Well that was probably mostly for comedic purposes. And i liked it, but to each their own.
Do I need an online password manager? Yeah, dude. I get to have strong, unique passwords that I would never be able to remember and, and this is the important part, it makes my life easier. Sure, an offline, encrypted password vault would be more secure, but also a huge pain in the ass. Not a good solution for usability
@@philrod1 You don't need a password manager if you use actual helpful passwords:
4s#@$345Adf is far worse than "A donkey puked on youtube after I saw fefes talk" or "My microsoft account is protected since 2020 because I use no Keepass".
Some passwords are not allowed to be long:
Random Sentence + Year of Creation + Website. Take only consonants & numbers
Xylophone Plays Well 2022 UA-cam -> XylphnPlysWll22YTb
After 5 Years or compromise use a different sentence.
1. already established
2. Write your business logic yourself and use well maintained other parts - as with the openssl lib he is actually using and not writing himself
3. That one take away as actually a HUGE one
4. But the industry IS dumb. IT buys crap because of compliance uses Cloud/Blockchain because of buzzwords and ignores Maintainability because of trading of 5% faster now vs 40% slower in 6 months. Doing something else is not smart, but common sense.
That maybe works in your private context, but how about distributing passwords in a company or even updating them. Tell me about a solution for that without the need of a password manager@@blinddarm8478
oh look at me, I can do it better..
The comments down here explain why "security - no even nice to have" is the accepted state of the world.
Shame he couldn’t answer the last question
Die Übertragung wurde unterbrochen.
20:40 instead of maintaining own journal maybe btrfs snapshots ??
First good criticism. But I would use it additionally - not "instead of"
I've had bosses who acted offended when I mention *books*, because they don't like to read, let alone code. In such an environment that privileges lowest bid, bottom of the barrel talent, small wonder the world is rife with exploitable security bugs.
great talk!
🎉
Gci is obsolete.
That's the thing, for his hardened blog it's perfect. If you ignore the needs of an industry, you can fall back to something simpler and hence safer.
Fefe 🙄
Rewrite everything from scratch in memory unsafe C is the way to write secure software?
That's not what he said.
We already implement much from scratch. This talk tells us to be more security conscious when we do
Also to avoid snake oil, but there aren't any managers watching this, and it's managers who buy the snake oil
@@ShenLong991 but that's what he did. There are so many open-source web servers written in memory safe languages out there which are better tested than his self-written solution. (he doesn't even do unit testing, yolo)
You can practice secure architecture in any language you have handy. Reducing the likelihood of common vulnerabilities by choosing a safer language should be combined with reducing the impact that any vulnerability could have using isolation and POLA.
@weichslgartner Look again at the description of the talk. The idea here is that following sandboxing / least-privilege principles, it doesn't really matter all too much if your application is insecure or vulnerable by itself. If the application only has very limited permissions from the OS and other parts of the architecture, there's little damage that you can do even if your app gets exploited.
Calling for waterfall development methology and bashing on agile as being a root-cause for insecure software devaluates the parts of the talk that are spot on. My eyebrows were already raised, when he mentioned "the old days" and implied that these were "the GOOD old days", which is usually "hindsight biased". No matter if you are designing a software or a hardware, good engineering uses "system thinking" and tries to "design for failure" (which this talk demonstrates with a tiny pet-project to explain the principles) .
But he didn't really. He just said you need to know exactly what you need to reduce the attack surface by writing and using only exactly what you need.
Everything you add additionally or leave there additionally is a risk factor. You can do this things with Agile development but it is very uncommon. It is more common to use libraries that do a lot of stuff you most likely don't need and don't understand. You basically can't make a risk assessment without knowing it. And it isn't feasible because it would take to long to work through giant amounts of code.
For example most xml libraries are extremely complicated, because they implement the hole xml standard. If you just want to parse/generate a bit of xml in a well defined format you don't need a lib.
the good old days when the grey beards thought null terminated strings were just great.
Expected way better. A little disappointed. Yes, the industry is full of blostware, but this talk was just not it.
I try to blame it on the talk being rejected and he not caring to even prepare it/optimize it.
To me it feels like something I did back in university/school two decades ago when I half assed something from the top of my head because somehow I had to present anyways.
Also he at least somewhat wakes up after 15 minutes, we have to give it to him :)
Not every talk needs to be perfect, some are just there to fill a schedule.
I disagree, I found it a fun and engaging talk on an interesting subject.
short awnser: it's impossible
First
I found the talk pretty meh for two reasons: 1. It is less about writing secure software and more about confining your software. 2. I like the principals that are presented, but I disagree with their implementation. Also instead of making fun of others, it would have been more helpful to actually explicitly adress these pricipals, instead of mostly implying. Makes it feel a bit like a circle jerk for those who already know alot about infosec and compsci. I like the whole comedy routine for Fnord, but here it's out of place.
ahh fefe. unhinged ranting, ignoring all surrounding complexity. you mean a blog you spent years hardening for fun has less attack surface than a company that has to run a whole lot more software, some of which they don't control, and with a market filled with developers less senior that are expected to deliver on a timeline? shock.
why do you invite this dude again, this is such a boring preachy talk.
He isn't uncorrect, this is how you in principle write correct software. It is also how you build public infrastructure that doesn't collapse etc. The fact that the majority of corporations does not manage doesn't mean he is incorrect here. If we built bridges like we build software they were constantly collapsing. I would read this as an ironic take on the state of the software industry, and as somone also working in software: He is totally spot on. Where other engineering disciplines would ask what the most simple, most reliable and most secure way to solve a problem is, software "developers" like to build jenga towers that are just a little less complex than they can nearly manage.
I wrote the same. A 10k enterprise cooperation has other use cases than a one-man-blog-show with 500 impressions per day. And that he is still using C completely disqualifies him for me to talk about secure software anyway.
I'd prefer that most web pages would be much simpler, save my band-width and don't annoy me with cookies and JavaScript or embedded videos, just like Fefe's blog. Actually most web sites do not need cookies nor scripts to work, it's simply for user tracking.
@@Windkind0 we build like that because managing the costs of collapse is more economical
If that applied to bridge-building too then we should expect to have bridges collapsing regularly.
I don't think it is __good__ that we as a discipline do that. But if the expected life of your product (and codebase) is like 2 years…
Places that are not preocuppied with meeting unreasonable time to market expectations don't tend to have these issues. (They hace other different issues IMO).