I'm not trying to be snarky, but it sounds like you have never had to implement an online payment system directly using a merchant account. If you've only used something like Stripe, there's a lot of requirements and compliance that the card companies do that has been abstracted away.
Visa & Mastercard have pretty singularly forced online payments to the level of security they are currently at. PCI compliance is pretty much solely driven by the card companies. If your payment details leak then yes, they want to issue you a new card. Half of that is making the customer feel better, but the other half is that the secrets need to be rotated since they've been exposed. SSH keys aren't vulnerable if generated properly, but if you expose the private key then the key needs rotated.
If you actually follow PCI compliance standards, there is no way to leak a customer's full payment details that I'm aware of. You could still leak other PII, but card # and CVC are something you can't access even with admin privileges on your recurring billing app.
So the card companies do quite a lot to protect against fraud and make people comfortable using their cards for online purchases. They just do this by requiring merchants to follow specific minimum practices. I'm not trying to glaze them, there is more they could do; and they do this to protect their bottom line. But fraud charges cost them a lot of money, and their interests align with consumers in this case to prevent fraud as much as they can.
It's 100% a racket. Your code could have been 10x worse and still passed, I doubt the auditors even looked at the code. It's a legal box-checking exercise, there really isn't much of an actual review besides the documentation. But my god is there a lot of documentation and paperwork.
If they don't have a strict requirement on SOC2, then either PCI compliance or NSA CISA are more easily done without needing tons of money.
Edit: PCI would only apply if you are processing customer funds Iirc, it's been a few years since I went through one but thereay be some caveats for that to apply.
Do they? Every time I've been asked about SOC compliance, it turned out the underlying reason was either insurance or a requirement the customer had from their downstream customer. Neither of those cases would be negotiable, the customer's insurance company only cares about a checkbox that "All vendors are SOC2 compliant and relevant documentation is on file".
That said, actually being SOC compliant isn't that hard aside from the paperwork aspect. Any competent firm should already be doing all the things required, it's the bare minimum for security. There really shouldn't be any code or process changes needed, if there are you are woefully inadequate from a security standpoint. SOC2 is below the bare minimum for actual security, but it's the standard firms have settled on.
That said, actually getting a valid SOC2 audit completed is expensive and for a solo dev you can expect at least a month of lost time. I wouldn't pay out-of-pocket for an audit, but if you're in a space where customers are asking it can be a selling point. One strategy would be to negotiate reduced terms with a potential client to use their auditing firm and have them split costs on the audit. This would need to be a very hot sales lead, since it's a big ask, but it might be worth exploring. They likely already have an established relationship with an auditor, and having a referral will cut the price down.
SOC is just a box ticking exercise and doesn't improve security at all. Or at least it shouldn't, if you don't already meet their requirements you need to either shut down your side hustle or completely revamp your processes. That said, the box-ticking is extremely tedious and involves reams of paperwork. It would be doable as a solo entrepreneur, I worked through the process in a company of 6 employees, but it's not fun or productive.
> History shows that "meh, ASLR mitigates this" is a vastly bolder claim anyway, so I don't feel much need to defend my position here.
Obviously you need to defend, that is quite generalization there. You need to prove how the vulnerability itself reduces the entropy of ASLR.
The authors don't really give support for that. They just say that they can brute-force it without crashing the whole Nginx. But they don't say how the entropy is reduced. They have zero information where the child process even starts, whether they hit the child, or if it even is the same child. So you should provide us technical and precise reasoning why it is not mitigating?
> Not really? Looks like we have a controlled-length overflow on a fork-based server, a situation where ASLR is known to not be very useful.
It does not work like that - it has certain pre-condition requirements. You also need a reliable oracle which tells information when you actually hit the child process, whether child crashes and whether you are even in the same child. When you can retrieve this information, you are then removing re-randomization between attempts. That reduces the entropy, but it only helps if remaining search space is small enough. They don't show that they have oracle.
Additionally, for RCE, you need to find libc base and that is randomized alone. Authors just ignored in the post how they got that address. For that, you most likely need the information leak from second vulnerability, even if you can brute force the actual vulnerability.
>It does not work like that - it has certain pre-condition requirements. You also need a reliable oracle which tells information when you actually hit the child process, whether child crashes and whether you are even in the same child. When you can retrieve this information, you are then removing re-randomization between attempts. That reduces the entropy, but it only helps if remaining search space is small enough. They don't show that they have oracle.
Why are you assuming there's any re-randomization going on? There isn't. That's a proposed mitigation to address this known problem with fork-based servers.
Plus, I've never understood the argument that cloud is better because you don't need to deal with the complexity of managing a server. Yes, it's a very deep topic and there's a lot of nuances to managing a Linux box serving web content, but we've been doing that for decades and there is tons of information and tooling available.
Every time I've needed to manage something on AWS I've been shocked at just how over wrought the whole system is. There's tons of As-specific terminology for everything, and lots of stuff is tremendously complicated to manage. I can definitely understand why companies need to hire people who are experts in AWS specifically, it's complicated enough to justify that. However, for me personally I'd rather learn more traditional sysadmin systems. The skills are more evergreen, and I'd rather spend my time learning open systems than one tech giant's specific system.
About 6 months ago I needed to migrate some of our systems from DigitalOcean to Hetzner. It was a 2 day process that was very painless. The only complicated bit was managing the DNS switchover with zero downtime. If we were moving those same 3 components from AWS to GCP or Azure, it would have involved needing to rearchitect and rewrite a lot of software.
I took a very similar class 9 years ago, and it was honestly one of the most helpful things I got out of my CS degree. The low level and limited tooling taught me to think before I start writing.
I've had other people look askanse at me, but on greenfield work I tend to start with pen and graph paper. I'm not even writing pseudocode, but diagramming a loose graph with potential functions or classes and arrows interconnecting them. Obviously this can be taken too far, full waterfall planning will be a different exercise in frustration.
I find spending a few hours planning out ahead of time before opening an editor saves me tons of time actually coding. I've never had a project even loosely resemble the paper diagram, but the exercise of thinking through the general structure ahead of time makes me way more productive when it comes time to start writing code. I've tried diagramming and scaffolding in my editor, but then I end up actually writing code instead of big picture diagramming. Writing it on paper where I know I'll have to retype everything anyway removes the distractions of what method to use or what to name a variable.
The few times I've vibe-coded something this was super helpful, since then I can give much more concrete and focused prompts.
In my experience the last several years, primarily we’re all on Zoom waving our hands and making false promises to update Confluence with what we talked about. I miss offices with walls and whiteboards.
I have theee whiteboards in ly office, and almost all the walls of my teams space is covered with whiteboards. They are always full and it is always a drama when some space need to be made
I'm on mobile so can't easily pull up an example part number, but digital signage controllers can often be PoE powered. They're insanely overpriced new from the actual suppliers, but for hobby projects they can normally be sourced relatively easily on ebay. The trick is that many of the ebay sellers don't bother listing the specs, so you need to first search digital sign cintroller/computer on ebay then look up the spec sheet from the model number.
Every programming job I've ever had, I've been required at certain points to make open source contributions. Granted, that was always "we have an issue with this OSS library/software we use, your task this sprint is to get that fixed".
I won't say never, but it would take an exceedingly large comp plan for me to sign paperwork forbidding me from working on hobby projects. That's pretty orwellian. I'm not allowed to work on hobby projects on company time, but that seems fair, since I also can't spend work hours doing non-programming hobbies either.
I don't expect radiologists to have a good understanding of the software involved in the control loops for the equipment they operate. Why should a lawyer have to have a mental model or even understand how the pdf rendering engine works?
Have you ever had to actually react a document in acrobat pro? It's way more fiddly and easy to screw up than one would expect. Im not saying professionals shouldn't learn how to use their tools, but the UI in acrobat is so incredibly poor that I completely understand when reaction gers screwed up. Up thread there's an in complete but very extensive list of this exact thing happening over and over. Clearly there's a tools problem here. Actual life-critical systems aren't developed this way, if a plane keeps crashing due to the same failure we don't blame the pilot. Boeing tried to do that with the max, but they weren't able to successfully convince the industry that that was OK.
if a plane keeps crashing due to the same failure we don't blame the pilot
That's true, we blame the manufacturer and demand that they fix their product under threat of withdrawing the airworthiness certification. So where's the demand for Adobe to fix its software, under pain of losing their cash cow?
Yet, people here are arguing that it is perfectly OK that professionals keep working with tools that are apparently widely known to be inappropriate for their task. Why should we not blame the lawyers that authorized the use of inappropriate tooling for such a sensitive task as legal redaction of documents?
Visa & Mastercard have pretty singularly forced online payments to the level of security they are currently at. PCI compliance is pretty much solely driven by the card companies. If your payment details leak then yes, they want to issue you a new card. Half of that is making the customer feel better, but the other half is that the secrets need to be rotated since they've been exposed. SSH keys aren't vulnerable if generated properly, but if you expose the private key then the key needs rotated.
If you actually follow PCI compliance standards, there is no way to leak a customer's full payment details that I'm aware of. You could still leak other PII, but card # and CVC are something you can't access even with admin privileges on your recurring billing app.
So the card companies do quite a lot to protect against fraud and make people comfortable using their cards for online purchases. They just do this by requiring merchants to follow specific minimum practices. I'm not trying to glaze them, there is more they could do; and they do this to protect their bottom line. But fraud charges cost them a lot of money, and their interests align with consumers in this case to prevent fraud as much as they can.
reply