48 ms·

Will there be ways in the foreseeable future to prove that software is free of vulnerabilities (using formal proofs and similar)? Because with all these vulner

by aborsy 3y ago

Will there be ways in the foreseeable future to prove that software is free of vulnerabilities (using formal proofs and similar)? Because with all these vulnerabilities hidden in piles of code, the situation sounds hopeless.

not_your_vase 3y ago
There are 2 types of engineers. Generic Engineer, "Engineerius Domesticus" - Like an architect or civil engineer. If they make a fatal mistake, especially one that can be avoided with best practices, they will never be allowed to work in their profession again. Possibly they go to jail. Software Engineer, "Engineerius Softwarus Sapiens Sapiens Sapiens Sapiens" - If they make a fatal mistake, especially one that can be avoided with best practices, there will be a blameless post mortem/retrospective where everyone gets a pat on the back, exclaiming "what a great job everyone did, this was really unavoidable, if we disregard the fact that it was completely avoidable". The smartest guy in the room has already an offer from another employer where he will make the very same mistake. As long as this doesn't change, and software developers have exactly 0 incentive to write code that's at least "not garbage", please enjoy your bugs.
- move-on-by 3y ago
  From a legal sense- at least in the USA- we are not engineers. Actual engineers must pass a FE (Fundamentals of Engineering) exam. After 4 years working under a Professional Engineer, you can apply to take the PE exam and become a Professional Engineer as well- with the ability to ‘stamp’ (approve) designs. That is when you are liable. There are continuing education requirements to maintain the status. Rules vary by state, and some states have reciprocity agreements. Until we have that for software ‘engineering’, we are not engineers and do not have the same requirements and liabilities.
- tracker1 3y ago
  If you can convince someone to go back to 1960's models and pay for software development where planning is literally measured in years for what gets done in a few months today, more power to you. I don't mean to be completely snarky, but that's the reality of it.. most software isn't a skyscraper, or even a medical device of vehicle.. most software is CRUD with some business rules thrown in. A given system goes down it's an inconvenience but nobody actually dies. You aren't going to hire a team of architects to design and review a dog house. And if you think the latter can't apply to physical things, look at some of the case reviews from Gamer's Nexus... many are literally unfit for their own duty. A recent NAS case review on a different channel showed it had to be Dremel modified in order to even work. Similar for the NAS case recently used by DeBauer. It actually happens plenty with physical goods. The comparison really bugs me. It does indeed bug me when there's a direct connection from the entertainment system in a car and the drive train, for example... that isn't abstracted away via physical device + api. Similar can be said for some decisions with Aerospace equipment. In the end, can you name the engineer that is never working again because the accelerator in some car models tended to get stuck? I can't.
  - not_your_vase 3y ago
    "It crap, but at least it is generated fast" - cool. Cars are a bit special in this regard. When a house is built, it's architect will be registered, and punished, if needed. When a car is created, it is created by a brand, like Ford. When there is a recall, you only hear that it's Ford's or Tesla's fault. But at the moment when they see that there is a problem, they will frantically search in change history to see who caused the problem. If you think that this person gets a raise instead of a permanent burger flipping job at a McDonald's, then I got a nice bridge to sell that you might be interested in.
    - tracker1 3y ago
      Feel free to start your own development company, doing things how you suggest and get or provide the funding as you like. I wish you all the best in such and endeavor.
- PoignardAzur 3y ago
  > Software Engineer, "Engineerius Softwarus Sapiens Sapiens Sapiens Sapiens" - If they make a fatal mistake, especially one that can be avoided with best practices, there will be a blameless post mortem/retrospective where everyone gets a pat on the back, exclaiming "what a great job everyone did, this was really unavoidable, if we disregard the fact that it was completely avoidable". The smartest guy in the room has already an offer from another employer where he will make the very same mistake. Oh come on. The point of a blameless post-mortem is to avoid ass-covering and other concealment of critical information from the responsible parties. It's not about patting yourself on the back, it's about creating an environment where mistakes can be quickly identified and fixed. If you're of the mindset that the only way to create a safe system is to put a gun to the engineer's head, then yeah, that's a bad deal. If you're of the mindset that human errors will happen no matter how much you intimidate and punish your engineers, your priority becomes figuring out processes that are resilient to human error, and blameless post-mortems are a part of that.
- jiggawatts 3y ago
  I have an email in my inbox just this morning from a developer with the magic phrase “I just want to…” in it. I mentally auto complete the suffix as: “disregard security requirements, ignore best practices, cut corners, do the needful at someone else’s expense, etc…” There is no scenario where the rest of the sentence is “…do the right thing.” I get an email like this weekly at a minimum. This one is asking to punch an unauthorised, unauthenticated, unaudited path from the Internet to legacy servers on the network that will go end-of-life in a month. Exposing the gooey vulnerable insides of a huge network to direct attack. I’ll politely refuse. He’ll just go to someone else, who won’t refuse. You can assume the same scenario plays out every few seconds world-wide. It might be code review, or using a hard-coded credential “just for now”, or whatever. This is the typical reality of software development. From what I’ve heard, embedded and industrial control software is worse still.
  - midoridensha 3y ago
    >From what I’ve heard, embedded and industrial control software is worse still. Avionics software is not like this at all. There's a reason you never hear about software failures in airplanes. (Before some wise-ass says something about the Boeing MCAS in the 737MAX, that wasn't a software failure. The software worked perfectly, flying the planes into the ground exactly was it was designed to do by the systems engineers and corporate executives who conceived of MCAS and thought it'd be a great idea to take input from a single sensor.) Industrial control software is pretty bad though.
  - rbreaves 3y ago
    You sound like a bundle of joy. To me it all depends on the situation - but I’ve dealt w/ network engineers that really had no business being over it or any real understanding of Linux, ssh, tunnels, etc. He was constantly ignoring my work related requests that absolutely needed resolution in 4-48hrs so I just stopped communicating w/ him. The moment I gained access to a staging server that wasn’t locked down to hell & back I forwarded whatever ports & level of access that I needed. It’d have served the company better to give me the permissions to open up ports & access as I needed in the first place, devs need access to what they’re dev’ing or running against but given the level of quality people I was dealing w/ I just gave up & granted myself access in other ways vs opening up support tickets all the time. I did recently gain access to an employee that was on it though & used common sense - sadly they’ve resigned & I don’t know why but I do know it’s a HUGE loss. They had some amazing side projects going on too - the guy was valuable imo & an effort to keep him should have been made if it hadn’t.
huijzer 3y ago
There are infinite ways to "hack" any system, this includes social engineering, timing attacks etc etc, so I don’t think so.
PoignardAzur 3y ago
There are tools you can use to eliminate or mitigate whole classes of vulnerabilities: memory-safe languages, sandboxing, having a capability-based OS, etc. They're not widespread, but they reduce your attack surface a lot.
Veserv 3y ago
Well first we should stop using code that was not intended or designed to be secure. If you are making a airplane you buy aerospace-grade screws. You do not go down to Home Depot, get some screws out of a box and hope for the best. Ask any of the software developers making these systems if they feel comfortable that people could die if their code has defects. Most would answer no. These systems should be rejected outright, to no fault of the developers who were probably not even told in what situations their code was going to be used. Anybody answering yes, should have their code carefully scrutinized in much the same way we scrutinize other safety-critical systems such as the mechanical components of bridges, airplanes, medical devices and cars. Any company using systems unfit for purpose must either demonstrate that their processes make their inputs fit for purpose or should face civil and/or criminal charges for willfully endangering the public.
- NoPicklez 3y ago
  I and most would completely agree with this. The challenge is that even despite these measures vulnerabilities will still be found and exploited. In the same way that critical safety systems are also found to have vulnerabilities. In my opinion what needs to be done and should be done, is looking at the network as a whole and thinking about how you can mitigate the impacts of potential vulnerabilities and designing the entire network with defence in depth. If it's a critical OT system that controls a power plant which could kill or injure someone, then it should realistically be completed air gapped as a first point of all.
hulitu 3y ago
> Will there be ways in the foreseeable future to prove that software is free of vulnerabilities (using formal proofs and similar)? There are already ways to prove that software is free of vulnerabilities. But they are expensive and time consuming. And the general trend of ignoring the user does not help either. > Because with all these vulnerabilities hidden in piles of code, the situation sounds hopeless.

by aborsy 3y ago

not_your_vase 3y ago

There are 2 types of engineers. Generic Engineer, "Engineerius Domesticus" - Like an architect or civil engineer. If they make a fatal mistake, especially one that can be avoided with best practices, they will never be allowed to work in their profession again. Possibly they go to jail. Software Engineer, "Engineerius Softwarus Sapiens Sapiens Sapiens Sapiens" - If they make a fatal mistake, especially one that can be avoided with best practices, there will be a blameless post mortem/retrospective where everyone gets a pat on the back, exclaiming "what a great job everyone did, this was really unavoidable, if we disregard the fact that it was completely avoidable". The smartest guy in the room has already an offer from another employer where he will make the very same mistake. As long as this doesn't change, and software developers have exactly 0 incentive to write code that's at least "not garbage", please enjoy your bugs.

move-on-by 3y ago
From a legal sense- at least in the USA- we are not engineers. Actual engineers must pass a FE (Fundamentals of Engineering) exam. After 4 years working under a Professional Engineer, you can apply to take the PE exam and become a Professional Engineer as well- with the ability to ‘stamp’ (approve) designs. That is when you are liable. There are continuing education requirements to maintain the status. Rules vary by state, and some states have reciprocity agreements. Until we have that for software ‘engineering’, we are not engineers and do not have the same requirements and liabilities.
tracker1 3y ago
If you can convince someone to go back to 1960's models and pay for software development where planning is literally measured in years for what gets done in a few months today, more power to you. I don't mean to be completely snarky, but that's the reality of it.. most software isn't a skyscraper, or even a medical device of vehicle.. most software is CRUD with some business rules thrown in. A given system goes down it's an inconvenience but nobody actually dies. You aren't going to hire a team of architects to design and review a dog house. And if you think the latter can't apply to physical things, look at some of the case reviews from Gamer's Nexus... many are literally unfit for their own duty. A recent NAS case review on a different channel showed it had to be Dremel modified in order to even work. Similar for the NAS case recently used by DeBauer. It actually happens plenty with physical goods. The comparison really bugs me. It does indeed bug me when there's a direct connection from the entertainment system in a car and the drive train, for example... that isn't abstracted away via physical device + api. Similar can be said for some decisions with Aerospace equipment. In the end, can you name the engineer that is never working again because the accelerator in some car models tended to get stuck? I can't.
- not_your_vase 3y ago
  "It crap, but at least it is generated fast" - cool. Cars are a bit special in this regard. When a house is built, it's architect will be registered, and punished, if needed. When a car is created, it is created by a brand, like Ford. When there is a recall, you only hear that it's Ford's or Tesla's fault. But at the moment when they see that there is a problem, they will frantically search in change history to see who caused the problem. If you think that this person gets a raise instead of a permanent burger flipping job at a McDonald's, then I got a nice bridge to sell that you might be interested in.
  - tracker1 3y ago
    Feel free to start your own development company, doing things how you suggest and get or provide the funding as you like. I wish you all the best in such and endeavor.
PoignardAzur 3y ago
> Software Engineer, "Engineerius Softwarus Sapiens Sapiens Sapiens Sapiens" - If they make a fatal mistake, especially one that can be avoided with best practices, there will be a blameless post mortem/retrospective where everyone gets a pat on the back, exclaiming "what a great job everyone did, this was really unavoidable, if we disregard the fact that it was completely avoidable". The smartest guy in the room has already an offer from another employer where he will make the very same mistake. Oh come on. The point of a blameless post-mortem is to avoid ass-covering and other concealment of critical information from the responsible parties. It's not about patting yourself on the back, it's about creating an environment where mistakes can be quickly identified and fixed. If you're of the mindset that the only way to create a safe system is to put a gun to the engineer's head, then yeah, that's a bad deal. If you're of the mindset that human errors will happen no matter how much you intimidate and punish your engineers, your priority becomes figuring out processes that are resilient to human error, and blameless post-mortems are a part of that.
jiggawatts 3y ago
I have an email in my inbox just this morning from a developer with the magic phrase “I just want to…” in it. I mentally auto complete the suffix as: “disregard security requirements, ignore best practices, cut corners, do the needful at someone else’s expense, etc…” There is no scenario where the rest of the sentence is “…do the right thing.” I get an email like this weekly at a minimum. This one is asking to punch an unauthorised, unauthenticated, unaudited path from the Internet to legacy servers on the network that will go end-of-life in a month. Exposing the gooey vulnerable insides of a huge network to direct attack. I’ll politely refuse. He’ll just go to someone else, who won’t refuse. You can assume the same scenario plays out every few seconds world-wide. It might be code review, or using a hard-coded credential “just for now”, or whatever. This is the typical reality of software development. From what I’ve heard, embedded and industrial control software is worse still.
- midoridensha 3y ago
  >From what I’ve heard, embedded and industrial control software is worse still. Avionics software is not like this at all. There's a reason you never hear about software failures in airplanes. (Before some wise-ass says something about the Boeing MCAS in the 737MAX, that wasn't a software failure. The software worked perfectly, flying the planes into the ground exactly was it was designed to do by the systems engineers and corporate executives who conceived of MCAS and thought it'd be a great idea to take input from a single sensor.) Industrial control software is pretty bad though.
- rbreaves 3y ago
  You sound like a bundle of joy. To me it all depends on the situation - but I’ve dealt w/ network engineers that really had no business being over it or any real understanding of Linux, ssh, tunnels, etc. He was constantly ignoring my work related requests that absolutely needed resolution in 4-48hrs so I just stopped communicating w/ him. The moment I gained access to a staging server that wasn’t locked down to hell & back I forwarded whatever ports & level of access that I needed. It’d have served the company better to give me the permissions to open up ports & access as I needed in the first place, devs need access to what they’re dev’ing or running against but given the level of quality people I was dealing w/ I just gave up & granted myself access in other ways vs opening up support tickets all the time. I did recently gain access to an employee that was on it though & used common sense - sadly they’ve resigned & I don’t know why but I do know it’s a HUGE loss. They had some amazing side projects going on too - the guy was valuable imo & an effort to keep him should have been made if it hadn’t.

huijzer 3y ago

There are infinite ways to "hack" any system, this includes social engineering, timing attacks etc etc, so I don’t think so.

PoignardAzur 3y ago

There are tools you can use to eliminate or mitigate whole classes of vulnerabilities: memory-safe languages, sandboxing, having a capability-based OS, etc. They're not widespread, but they reduce your attack surface a lot.

Veserv 3y ago

Well first we should stop using code that was not intended or designed to be secure. If you are making a airplane you buy aerospace-grade screws. You do not go down to Home Depot, get some screws out of a box and hope for the best. Ask any of the software developers making these systems if they feel comfortable that people could die if their code has defects. Most would answer no. These systems should be rejected outright, to no fault of the developers who were probably not even told in what situations their code was going to be used. Anybody answering yes, should have their code carefully scrutinized in much the same way we scrutinize other safety-critical systems such as the mechanical components of bridges, airplanes, medical devices and cars. Any company using systems unfit for purpose must either demonstrate that their processes make their inputs fit for purpose or should face civil and/or criminal charges for willfully endangering the public.

NoPicklez 3y ago
I and most would completely agree with this. The challenge is that even despite these measures vulnerabilities will still be found and exploited. In the same way that critical safety systems are also found to have vulnerabilities. In my opinion what needs to be done and should be done, is looking at the network as a whole and thinking about how you can mitigate the impacts of potential vulnerabilities and designing the entire network with defence in depth. If it's a critical OT system that controls a power plant which could kill or injure someone, then it should realistically be completed air gapped as a first point of all.

hulitu 3y ago

> Will there be ways in the foreseeable future to prove that software is free of vulnerabilities (using formal proofs and similar)? There are already ways to prove that software is free of vulnerabilities. But they are expensive and time consuming. And the general trend of ignoring the user does not help either. > Because with all these vulnerabilities hidden in piles of code, the situation sounds hopeless.