Right, of course no peripheral information is transmitted by a ciphertext in a one-time-pad. This is not what I meant by 'breaking', however; the application in question contains a verification oracle.
There is a difference between saying a problem is computationally infeasible and that it is believed to be hard. When we say something like 'a sufficiently sized one-time-pad is mathematically impossible to break', it is something of a hyperbole. Of course it's/mathematically/ possible, a simple guessing algorithm will terminate and output the plaintext and the pad. However, as has been observed, to do this with, say a 512-bit pad would require much more energy then is available to us on this planet assuming the theoretical bounds for energy consumption can be reached!
What is interesting to note however, is that the 'hard' problems we use in most string crypto are not/known/ to be infeasible, as is the one-time pad. We simply haven't found feasible solutions, nor have we found complexity analyses for these problems that demonstrate feaasible solutions to be possible. The effective difference is that it would be quite possible (although unlikey, since generations of the best mathematicians have been working on these problems) for someone to come along and demonstrate a solution to a particular problem, rendering a particular class of cryptographic methods useless...
On my system, I pre-empted this into the valid shells with shell-specific methods (alias for/bin/sh,/etc/profile for bash, etc) and since I have a small pid tracking library script in my startups, I was able to set the variable there as well.
This leaves some random daemons whose startup scripts are automatically installed and aren't aware of my startup library, and use scripts that aren't valid shells or actual binaries directly, or adding a shell to the init file corresponding to it.
On my system there were only a few of these, so I replaced the binaries/scripts with two-line bash scripts that simply executed the original file.
Hum. I suppose you could write a exec* wrapper that inserts the environment variable always. That could definitely be system-wide, always, but then we're leaving the realm of 'Easy'. Well, maybe not. It wouldn't take so many lines, but you'd have to mess around with library symbols and stuff.
Also, cron jobs! Same problem... Although these are much less likely to get arbitrary, malicious input.
I really meant "Easier than recompiling everything statically linked on my system right now in case someone figures out an exploit", rather than 'Easy' in a one-liner sense, I guess.:/
Oooh. After looking at that, I'm definitely in complete agreement with you... I do still wonder about comparative performance, but in this case I suppose it would be very hard to produce a benchmark with any concrete meaning.
Where do you perceive people regarding BSD as inferior? Just in general? I haven't played with it much myself, except doing superficial administrative type things.
No, of course one bias is never always correct! It's especially difficult to say for something like the ?alloc/free calls, which have potential security implications as well as consuming a significant amount of most programs' time.
I just wanted to point out that the bias was there.
This is not entirely accurate.
See my earlier post: about a workaround.
Mind you, the manpage cited/is/ annoyingly vague about the behavior of this facility, but you should keep in mind there is a performance/feature tradeoff, and your criticism assumes we should strive for robustness over performance.
Well, it won't prevent the DoS aspect - but, from the malloc manpage:
Recent versions of Linux libc (later than 5.4.23) and GNU libc (2.x) include a malloc implementation which is tunable via environment variables. When MALLOC_CHECK_ is set, a special (less efficient) implementation is used which is designed to be tolerant against simple errors, such as double calls of free() with the same argument, or overruns of a single byte (off-by-one bugs). Not all such errors can be proteced against, however, and memory leaks can result. If MALLOC_CHECK_ is set to 0, any detected heap corruption is silently ignored; if set to 1, a diagnostic is printed on stderr; if set to 2, abort() is called immediately. This can be useful because otherwise a crash may happen much later, and the true cause for the problem is then very hard to track down.
Seems worth it while all pour through the symbol tables of our static binaries (and recompile the stripped ones. =( )
On another note, I've always regarded security bulletins as a one-way process... For example, I couldn't find a way to tell RedHat they'd omitted this (seemingly important?) reminder. Any thoughts about this? (admittedly i didn't look very hard for very long)
Slashdot Mirror
From the fortune file that ships with Slack: (is this an original BSD fortune?)
Demand the establishment of the government in its rightful home at Disneyland.
And how right they were...
Right, of course no peripheral information is transmitted by a ciphertext in a one-time-pad. This is not what I meant by 'breaking', however; the application in question contains a verification oracle.
There is a difference between saying a problem is computationally infeasible and that it is believed to be hard. When we say something like 'a sufficiently sized one-time-pad is mathematically impossible to break', it is something of a hyperbole. Of course it's /mathematically/ possible, a simple guessing algorithm will terminate and output the plaintext and the pad. However, as has been observed, to do this with, say a 512-bit pad would require much more energy then is available to us on this planet assuming the theoretical bounds for energy consumption can be reached!
/known/ to be infeasible, as is the one-time pad. We simply haven't found feasible solutions, nor have we found complexity analyses for these problems that demonstrate feaasible solutions to be possible. The effective difference is that it would be quite possible (although unlikey, since generations of the best mathematicians have been working on these problems) for someone to come along and demonstrate a solution to a particular problem, rendering a particular class of cryptographic methods useless...
What is interesting to note however, is that the 'hard' problems we use in most string crypto are not
On my system, I pre-empted this into the valid shells with shell-specific methods (alias for /bin/sh, /etc/profile for bash, etc) and since I have a small pid tracking library script in my startups, I was able to set the variable there as well.
:/
This leaves some random daemons whose startup scripts are automatically installed and aren't aware of my startup library, and use scripts that aren't valid shells or actual binaries directly, or adding a shell to the init file corresponding to it.
On my system there were only a few of these, so I replaced the binaries/scripts with two-line bash scripts that simply executed the original file.
Hum. I suppose you could write a exec* wrapper that inserts the environment variable always. That could definitely be system-wide, always, but then we're leaving the realm of 'Easy'. Well, maybe not. It wouldn't take so many lines, but you'd have to mess around with library symbols and stuff.
Also, cron jobs! Same problem... Although these are much less likely to get arbitrary, malicious input.
I really meant "Easier than recompiling everything statically linked on my system right now in case someone figures out an exploit", rather than 'Easy' in a one-liner sense, I guess.
Oooh. After looking at that, I'm definitely in complete agreement with you... I do still wonder about comparative performance, but in this case I suppose it would be very hard to produce a benchmark with any concrete meaning. Where do you perceive people regarding BSD as inferior? Just in general? I haven't played with it much myself, except doing superficial administrative type things.
No, of course one bias is never always correct! It's especially difficult to say for something like the ?alloc/free calls, which have potential security implications as well as consuming a significant amount of most programs' time. I just wanted to point out that the bias was there.
This is not entirely accurate. See my earlier post: about a workaround. Mind you, the manpage cited /is/ annoyingly vague about the behavior of this facility, but you should keep in mind there is a performance/feature tradeoff, and your criticism assumes we should strive for robustness over performance.
Well, it won't prevent the DoS aspect - but, from the malloc manpage:
Recent versions of Linux libc (later than 5.4.23) and GNU libc (2.x) include a malloc implementation which is tunable via environment variables. When MALLOC_CHECK_ is set, a special (less efficient) implementation is used which is designed to be tolerant against simple errors, such as double calls of free() with the same argument, or overruns of a single byte (off-by-one bugs). Not all such errors can be proteced against, however, and memory leaks can result. If MALLOC_CHECK_ is set to 0, any detected heap corruption is silently ignored; if set to 1, a diagnostic is printed on stderr; if set to 2, abort() is called immediately. This can be useful because otherwise a crash may happen much later, and the true cause for the problem is then very hard to track down.
Seems worth it while all pour through the symbol tables of our static binaries (and recompile the stripped ones. =( )
On another note, I've always regarded security bulletins as a one-way process... For example, I couldn't find a way to tell RedHat they'd omitted this (seemingly important?) reminder. Any thoughts about this? (admittedly i didn't look very hard for very long)