3 ms·

> In any case, NSA can already do what you mentioned given leaks mention active targeting. I see it as a massive difference: dragnet scope, loss of forward sec

by woodman 10y ago

> In any case, NSA can already do what you mentioned given leaks mention active targeting. I see it as a massive difference: dragnet scope, loss of forward security due to precomputed magic numbers, etc. While the threat is hypothetical, unlike traffic analysis and active targeting, the consequences elevate it to a point where it deserves its own consideration. > ...on aforementioned can knock out vast majority of the risk. I'm usually a one bite at a time sort of guy when it comes to eating elephants, but I think a language switch should bring a little bit more benefit - especially considering the unsolved compiler optimizing security away problem (outside of language subsets enforced by self discipline). It is dangerous, and it has led to the slow death of many projects, but I'd recommend some time spent on custom tooling. The furthest I'd suggest would be language extensions, likely implemented as external llvm modules, nothing crazy - retaining array size metadata in function arguments instead of throwing the information away. ACSL for contract specification would be nice, or at least fix frama-c so that it isn't so awful. > They still need review. You have to specify... I was speaking of implementation changes to already specd functions, but after further consideration I want to double down. Any changes to code further down stream of well specified functions shouldn't need code review. That wouldn't be a very good way to go about it, one massive function specification instead of a composition, but it would still be secure. > ...covert channel analysis means it's going to be an imperative language for final implementation. Yeah I didn't mean a functional language like haskell, as I've yet to write any production quality code in it after several years of trying... I was thinking more along the lines of the function __attribute__((const)). This might make my no review suggestion not work, but that custom tooling might be able to help with detecting information leaks through variable loop iteration counts. Lots of ways to tackle the problem. > Mainstream INFOSEC totally ignored that problem... I can sympathize, I recognize it as a problem - and I try not to think about it because it makes me very sad.

nickpsecurity 10y ago
"the consequences elevate it to a point where it deserves its own consideration." Well, it does but maybe not here. Let's remember the situation. The consideration is only applying because a person openly said they're ex-CIA. So, we apply these considerations when people say that. Result? Instead of risk going away, they just stop saying they're ex-CIA. Maybe start talking about privacy, crypto, Anonymous, blockchains, and so on. Infiltration 101 applied to Tor project. Filtering out anyone claiming to be ex-government doesn't filter out ex-government except for those specific cases. This level of consideration, if infiltration risk is high, has to be all or nothing. "The furthest I'd suggest would be language extensions, likely implemented as external llvm modules, nothing crazy" It's a reasonable proposition. I considered something like Cyclone, a security-aware scheme for managing heap, and with JIF-style labels for information flow. Might knock out a lot of problems while keeping code mostly the same and able for C programmers to handle. https://en.wikipedia.org/wiki/Cyclone_(programming_language) https://en.wikipedia.org/wiki/Cyclone_(programming_language) https://www.cs.cornell.edu/jif/ https://www.cs.cornell.edu/jif/ " Any changes to code further down stream of well specified functions shouldn't need code review. " This is ambiguous. Are you saying that, with how they all interface, that any changes to lower-level functions should preserve interface invariants enough that higher-level stuff shouldn't have to be re-reviewed? If so, that would be reasonable. If not, please elaborate.
- woodman 10y ago
  > ...a person openly said they're ex-CIA. It was my understanding that he first misrepresented himself as a State Department employee, then for some reason came clean several years later. I think filtering that sort of behavior out has a lot more pros than cons. > I considered something like Cyclone... A lot of that can be done with compiler annotations, the disadvantage of course being that it isn't default behavior... which is consistent with the rest of the C universe - things are no more secure than you design them to be. > If not, please elaborate. That is what I'd say if I was an OO programmer, yes. But I'll elaborate anyway because... have you ever just been in the mood to write gibberish C? /* New unreviewed code from untrusted source */ __attribute__((const)) /* More pure than "pure" */ static int newfunc(char* src, int len){ return src ? 0 : len; } /* Imagine an incredibly comprehensive spec for this public function, right here */ __attribute__((nonnull(1,2))) /* No Cyclone needed for null safety here */ int pubfunc(char* a, char* b) { /* ... */ if (a[0] == '4') return newfunc(b, 4); /* Untrusted function covered under that amazing spec you imagined */ /* ... */ }

by woodman 10y ago

nickpsecurity 10y ago

"the consequences elevate it to a point where it deserves its own consideration." Well, it does but maybe not here. Let's remember the situation. The consideration is only applying because a person openly said they're ex-CIA. So, we apply these considerations when people say that. Result? Instead of risk going away, they just stop saying they're ex-CIA. Maybe start talking about privacy, crypto, Anonymous, blockchains, and so on. Infiltration 101 applied to Tor project. Filtering out anyone claiming to be ex-government doesn't filter out ex-government except for those specific cases. This level of consideration, if infiltration risk is high, has to be all or nothing. "The furthest I'd suggest would be language extensions, likely implemented as external llvm modules, nothing crazy" It's a reasonable proposition. I considered something like Cyclone, a security-aware scheme for managing heap, and with JIF-style labels for information flow. Might knock out a lot of problems while keeping code mostly the same and able for C programmers to handle. https://en.wikipedia.org/wiki/Cyclone_(programming_language) https://en.wikipedia.org/wiki/Cyclone_(programming_language) https://www.cs.cornell.edu/jif/ https://www.cs.cornell.edu/jif/ " Any changes to code further down stream of well specified functions shouldn't need code review. " This is ambiguous. Are you saying that, with how they all interface, that any changes to lower-level functions should preserve interface invariants enough that higher-level stuff shouldn't have to be re-reviewed? If so, that would be reasonable. If not, please elaborate.

woodman 10y ago
> ...a person openly said they're ex-CIA. It was my understanding that he first misrepresented himself as a State Department employee, then for some reason came clean several years later. I think filtering that sort of behavior out has a lot more pros than cons. > I considered something like Cyclone... A lot of that can be done with compiler annotations, the disadvantage of course being that it isn't default behavior... which is consistent with the rest of the C universe - things are no more secure than you design them to be. > If not, please elaborate. That is what I'd say if I was an OO programmer, yes. But I'll elaborate anyway because... have you ever just been in the mood to write gibberish C? /* New unreviewed code from untrusted source */ __attribute__((const)) /* More pure than "pure" */ static int newfunc(char* src, int len){ return src ? 0 : len; } /* Imagine an incredibly comprehensive spec for this public function, right here */ __attribute__((nonnull(1,2))) /* No Cyclone needed for null safety here */ int pubfunc(char* a, char* b) { /* ... */ if (a[0] == '4') return newfunc(b, 4); /* Untrusted function covered under that amazing spec you imagined */ /* ... */ }