4 ms·

> I rarely write code that connects to anything, so almost never? Sounds hard to believe. What kind of code would that be? > There's a lot of code that's not

by hannob 10y ago

> I rarely write code that connects to anything, so almost never? Sounds hard to believe. What kind of code would that be? > There's a lot of code that's not written by web devs. There's also a lot more than the web that has some form of connectivity with the Internet (even if it's not directly connected it may still parse data that comes from untrusted sources). There is a widespread belief among many that "security is important, but doesn't matter for me". The most extreme example is obviously IoT ("Who would want to hack my coffeemaker?"), but there's a lot more. The unfortunate truth is: There is hardly any code these days that is not security relevant.

nickpsecurity 10y ago
"Sounds hard to believe. What kind of code would that be?" You do realize there's a bajillion non-networked apps in existence? Word processors, excel, editors/IDE's, system tools (esp monitoring/backup), media players that don't download stuff, compression libraries, MATLAB-style tools for numeric analysis, and so on.
- hannob 10y ago
  > You do realize there's a bajillion non-networked apps in existence? Word processors, excel, editors/IDE's, system tools (esp monitoring/backup), media players that don't download stuff, compression libraries, MATLAB-style tools for numeric analysis, and so on. All of them parse potentially untrusted inputs. They don't have to be directly network connected to be a security risk. Just pick the first example: A word processor. It is not a security risk only if you can guarantee that you'll only ever open documents that you created yourself. If you ever use it to open documents you got from someone else it needs to take security into consideration.
- mwexler 10y ago
  Sadly, almost everything you mention involve opening files, and files are often on networks. Standard modal file|open on windows allows http:// http:// access to files on hosted servers, for example. Suddenly, all of these are potentially networked in the hands of users using the code for unintended purposes or in unexpected ways.
  - Jtsummers 10y ago
    But you don't write those dialogs yourself. You write code that calls the system file open dialog. Then, presumably, you do some check on the file for sanity checking (is it the right type? does it parse correctly? does the internal size # equal the value the OS is claiming?). If those checks fail, you report an error. Otherwise, you process it. The source doesn't matter at that point. And if there's a glitch in the dialog for handling HTTP or similar sources, then that's on the system developers to correct, and on you to report if you discover it.
    - nickpsecurity 10y ago
      Exactly. All the concerns of networking, the Internet, and the Web go away. It becomes an input validation problem. From there, one can do a format suitable for correct-by-construction auto-generation of the parser. Or can take the common route building a Turing machine into it to fight with over time. ;) Still not writing or patching a networked app.
      - Jtsummers 10y ago
        OT: Have you ever read Engineering a Safer World [0] by Nancy Leveson [1]? Seems like something that'd be of interest to you. Started on it this week, my sister is in her class this semester at MIT. I'll be tackling it over the next few weeks, and then her previous text (Safeware) after the new year. [0] https://mitpress.mit.edu/books/engineering-safer-world https://mitpress.mit.edu/books/engineering-safer-world [1] http://sunnyday.mit.edu/ http://sunnyday.mit.edu/
        nickpsecurity 10y ago
        Wow. Been studying high-assurance systems close to 10 years and just hearing about her. That's how scattered that field can be. Let's look at this. "Started new area of research: software safety." That was Bob Barton in Burroughs B5000, Dijkstra on THE, and Margaret Hamilton on Apollo code. Maybe they mean first dept at MIT or just making status of sub-field more official. Then TCAS II. I recall reading that long ago as an exemplary work in formal specification & safety analysis but project was too heavy for me. Article says them too haha. Props to her for it & others. Article shares my view on scattered groups & methods. At least seen STAMP referenced once but unfamiliar with it. They wrote against N-version programming being re-invented... which I proposed for subversion resistance. Hmmm. I'm sure my variant is the one that works this time. ;) Also did SpecTRM at their company that looks a lot like state machine and modeling schemes I saw elsewhere in high-assurance. Not claiming a copy rather than inspiration or independent invention + convergence of multiple parties. Usually means a good idea. Very interesting person. Thanks for the tip. Your sister is going to learn some wise things for sure given they've got sane methods and got results before. I especially liked how the article jokes about writing what she knew on high-assurance development then gotten wiser or more confused. I know the feeling where I'm redoing the foundations now with what a decade taught me. More slowly this time given I have more doubt than certainty. Note: Just got to the last part. Wait, she was the one who wrote the THERAC paper? I just assumed it was some guy (male-dominated field) named Levenson since that name was all I saw in references to the report. Never saw it again. So, she wrote up an investigation we've been citing about software safety for decades, helped spearhead efforts to legitimize it as a field, did huge projects, and I basically never hear about her. Unreal. I'm bookmarking her stuff to go through it later.
ryandrake 10y ago
> > I rarely write code that connects to anything, so almost never? > Sounds hard to believe. What kind of code would that be? Device drivers, compilers, and some embedded systems come to mind immediately, there are plenty of others out there. I've worked on a lots of software where the only inputs were physical and sensor based, and the only outputs were to the screen. Device didn't even physically have network equipment.
- hannob 10y ago
  Device drivers are a bad example, they can be extremely security sensitive (particularly so because they usually have kernel privileges). There are few things where security doesn't matter. But they are extremely rare. The situations where programmers think their code isn't security sensitive are probably vastly more common.
  - ryandrake 10y ago
    Good point, but I was addressing the perceived lack of "code that connects to anything". I agree with you that security is a valid concern for most if not all code written.
- RandomOpinion 10y ago
  >...device drivers... I hope you're joking but I suspect you're not. Device drivers have the highest level of privileged access in many operating systems and code quality for drivers is so uniformly lousy (certain large vendors whose names begin with "N", "A", and particularly "Q", I'm looking at you) that attempting to break the drivers would be among the first things I'd consider if I were trying to root a device.
  - ryandrake 10y ago
    Please see my other reply. I was addressing "unconnected software" not "software without attack surfaces". I agree that security is a concern with all software.
EpicEng 10y ago
I write code that interfaces with hardware (health care imaging systems), processes images, and a little computer vision here and there. Very few service calls in that stack. I jump up 1000 levels of abstraction from time to time, and when I do, I agree that security is extremely important (FDA class III device and HIPAA compliance is mandatory.) I'm also a lead, so I have to know enough to call BS when I hear it from a team member.

by hannob 10y ago

nickpsecurity 10y ago

"Sounds hard to believe. What kind of code would that be?" You do realize there's a bajillion non-networked apps in existence? Word processors, excel, editors/IDE's, system tools (esp monitoring/backup), media players that don't download stuff, compression libraries, MATLAB-style tools for numeric analysis, and so on.

hannob 10y ago
> You do realize there's a bajillion non-networked apps in existence? Word processors, excel, editors/IDE's, system tools (esp monitoring/backup), media players that don't download stuff, compression libraries, MATLAB-style tools for numeric analysis, and so on. All of them parse potentially untrusted inputs. They don't have to be directly network connected to be a security risk. Just pick the first example: A word processor. It is not a security risk only if you can guarantee that you'll only ever open documents that you created yourself. If you ever use it to open documents you got from someone else it needs to take security into consideration.
mwexler 10y ago
Sadly, almost everything you mention involve opening files, and files are often on networks. Standard modal file|open on windows allows http:// http:// access to files on hosted servers, for example. Suddenly, all of these are potentially networked in the hands of users using the code for unintended purposes or in unexpected ways.
- Jtsummers 10y ago
  But you don't write those dialogs yourself. You write code that calls the system file open dialog. Then, presumably, you do some check on the file for sanity checking (is it the right type? does it parse correctly? does the internal size # equal the value the OS is claiming?). If those checks fail, you report an error. Otherwise, you process it. The source doesn't matter at that point. And if there's a glitch in the dialog for handling HTTP or similar sources, then that's on the system developers to correct, and on you to report if you discover it.
  - nickpsecurity 10y ago
    Exactly. All the concerns of networking, the Internet, and the Web go away. It becomes an input validation problem. From there, one can do a format suitable for correct-by-construction auto-generation of the parser. Or can take the common route building a Turing machine into it to fight with over time. ;) Still not writing or patching a networked app.
    - Jtsummers 10y ago
      OT: Have you ever read Engineering a Safer World [0] by Nancy Leveson [1]? Seems like something that'd be of interest to you. Started on it this week, my sister is in her class this semester at MIT. I'll be tackling it over the next few weeks, and then her previous text (Safeware) after the new year. [0] https://mitpress.mit.edu/books/engineering-safer-world https://mitpress.mit.edu/books/engineering-safer-world [1] http://sunnyday.mit.edu/ http://sunnyday.mit.edu/
      - nickpsecurity 10y ago
        Wow. Been studying high-assurance systems close to 10 years and just hearing about her. That's how scattered that field can be. Let's look at this. "Started new area of research: software safety." That was Bob Barton in Burroughs B5000, Dijkstra on THE, and Margaret Hamilton on Apollo code. Maybe they mean first dept at MIT or just making status of sub-field more official. Then TCAS II. I recall reading that long ago as an exemplary work in formal specification & safety analysis but project was too heavy for me. Article says them too haha. Props to her for it & others. Article shares my view on scattered groups & methods. At least seen STAMP referenced once but unfamiliar with it. They wrote against N-version programming being re-invented... which I proposed for subversion resistance. Hmmm. I'm sure my variant is the one that works this time. ;) Also did SpecTRM at their company that looks a lot like state machine and modeling schemes I saw elsewhere in high-assurance. Not claiming a copy rather than inspiration or independent invention + convergence of multiple parties. Usually means a good idea. Very interesting person. Thanks for the tip. Your sister is going to learn some wise things for sure given they've got sane methods and got results before. I especially liked how the article jokes about writing what she knew on high-assurance development then gotten wiser or more confused. I know the feeling where I'm redoing the foundations now with what a decade taught me. More slowly this time given I have more doubt than certainty. Note: Just got to the last part. Wait, she was the one who wrote the THERAC paper? I just assumed it was some guy (male-dominated field) named Levenson since that name was all I saw in references to the report. Never saw it again. So, she wrote up an investigation we've been citing about software safety for decades, helped spearhead efforts to legitimize it as a field, did huge projects, and I basically never hear about her. Unreal. I'm bookmarking her stuff to go through it later.

ryandrake 10y ago

> > I rarely write code that connects to anything, so almost never? > Sounds hard to believe. What kind of code would that be? Device drivers, compilers, and some embedded systems come to mind immediately, there are plenty of others out there. I've worked on a lots of software where the only inputs were physical and sensor based, and the only outputs were to the screen. Device didn't even physically have network equipment.

hannob 10y ago
Device drivers are a bad example, they can be extremely security sensitive (particularly so because they usually have kernel privileges). There are few things where security doesn't matter. But they are extremely rare. The situations where programmers think their code isn't security sensitive are probably vastly more common.
- ryandrake 10y ago
  Good point, but I was addressing the perceived lack of "code that connects to anything". I agree with you that security is a valid concern for most if not all code written.
RandomOpinion 10y ago
>...device drivers... I hope you're joking but I suspect you're not. Device drivers have the highest level of privileged access in many operating systems and code quality for drivers is so uniformly lousy (certain large vendors whose names begin with "N", "A", and particularly "Q", I'm looking at you) that attempting to break the drivers would be among the first things I'd consider if I were trying to root a device.
- ryandrake 10y ago
  Please see my other reply. I was addressing "unconnected software" not "software without attack surfaces". I agree that security is a concern with all software.

EpicEng 10y ago

I write code that interfaces with hardware (health care imaging systems), processes images, and a little computer vision here and there. Very few service calls in that stack. I jump up 1000 levels of abstraction from time to time, and when I do, I agree that security is extremely important (FDA class III device and HIPAA compliance is mandatory.) I'm also a lead, so I have to know enough to call BS when I hear it from a team member.