News for hackers. Stuff that matters.
Re:Being Sneaky in C by ape4 on Friday June 12, 2015 @05:17PM (#9708602)
Yes, memset_s(). Which makes me think there should be a free_s().
Re:Being Sneaky in C by TheLoneWolfling on Saturday June 13, 2015 @12:09AM (#9709830)
memset_s, or a mythical free_s, is not enough.

The compiler can, and will, make copies of data behind the scenes. And not erase said copies.

What we really need is a keyword / modifier that says that when X passes out of scope no state related to X may be leaked. Ideally, that can be applied to a function / block as well as a variable.

(Or rather, not necessarily no state. Read "as little state as possible", preferably with modifiers that panic unless the compiler can ensure specific things.)

Re:Being Sneaky in C by mpu on Saturday June 13, 2015 @10:21AM (#9711071)
The C standard works at an abstraction level that makes it unsuitable for security applications, I would advocate for a new language here. It needs serious PL research with informarion flow reasoning, what we need is just a new kind of language much more machine aware (yes, more low-level) than C.
Re:Being Sneaky in C by TheLoneWolfling on Saturday June 13, 2015 @10:49AM (#9711157)
Agreed on some level.

On the other hand, something as simple as a keyword marking a variable as "as secure as possible given hardware constraints (read: should wipe any temporary copies and the variable itself after it goes out of scope, should attempt to prevent it from being written to non-volatile storage, that sort of thing)" (sort of like how inline works), with compilers required to bail if the constraint cannot be done to the level specified, would be a massive step in the right direction.