Well your initial conjecture was that using the heap was bad, and then you proceeded to use the heap. Furthermore, are you saying that good coding practices dictate that one doesn't use the heap and instead allocates on the stack?? I think I may have misunderstood you, but I'm not sure. It's kind of absurd to presume that just because you're using new/delete or using destructors/constructors that you're in the clear, in fact heap exploitation is moving in the direction of attacking the objects themselves instead of heap metadata (although that point is largely irrelevant to the matter at hand)
Finally, there was no memory leak, the resources would be returned to the system when the program exited. While it would've been proper to deallocate the memory and then exit, it really doesn't matter if all he did was exit.
Regardless of what they believe it to be at the time, they patched it promptly. The label of being an issue of reliability or security, is merely to vaguely inform users of the severity. It was patched promptly and then later found to be a security issue, which the OpenBSD project publically acknowledged.
Indeed it was promptly patched and I won't attempt to take that away. My question was more in dealing with the motives of calling it reliability instead of security, and one has to wonder how many other reliability patches there are out there and if this pablumification of security patches does a greater disservice to the OpenBSD userbase ('oh its not an important patch it can wait till a stable release/monday/whatever').
What would you know the OpenBSD project ATTEMPTED to say and where did you find the word "impossible" from the OpenBSD project in this matter? Why don't we stick with what they DID say. I don't want YOUR interpretation. What they DID say, was "it would be surprising to be able to run arbitrary code".
The OpenBSD project "would be surprised", they then subsequently were surprised and promptly upgraded the status from a reliability issue, to one of security.
You are indeed correct, that was poor wording on my part and was not so much an attempt to mislead on my part but rather a case of being inarticulate. My overall point however still remains, was this a truthful impression or more egotistical blabber in an attempt to avoid admitting to another bug in the default install? And that this makes me question their firm belief in security because they put their users at risk by silently patching, redefining terms and contorting security fixes to be reliability fixes.
The "vendor" DOES consider them bugs. They just draw the distinction that the bug IS KNOWN to cause a reliability issue, but is NOT CURRENTLY ***BELIEVED*** TO BE A SECURITY ISSUE. Where "security issue" includes the running of arbitrary code and therefore potentially the gaining of remote access.
Misuse of the word on my part, I meant to say vulnerability. The fact that the OpenBSD team does not consider them a vulnerability is absolutely fucking absurd. I work as a security researcher and my company will not let us release advisories for things that are only DoS attacks, so I understand the difference but there are plenty of security implications from a DoS, even if it is not as useful or glamorous as remote code execution.
My overall point is that I can't help but wonder if the choice to not refer to it as a security vulnerability has to do with the desire to not modify the 'x bugs in x years' line.
The "party line" is a statement of fact. How you interpret it is up to you. I take it merely as a statement which reflects the ATTITUDE of the leadership behind the OpenBSD project. Anyone who took it as something more than that, probably ought to be running something else, since they clearly are not capable of understanding the significance of "secure by default". It does not mean our software is absolutely secure, it means our software installs and exposes little by default. It is a clean system for which to build upon, as opposed to a kitchen sink system to whittle down.
It's a statement of contorted facts, I've kept a fairly close eye on the changelog off and on and am aware of the number of reliability fixes in there, and I've even dug into some of them, and I will leave it at that, but it will be interesting to see how many reliability fixes come out in the IPv6 code, which is incredibly shaky (and then digging backwards how many reliability fixes have there been dealing with mbuf's? more than one, I know that).
Taking it as a sign of the attitude is absurd and thats like nike saying that their claims to not run sweatshops was covered by their first ammendment rights.
BTW, I am not the other AC you have been talking with, however I do work in the industry. Also like you (I'm assuming here), in a research capacity (expert witness) f
So you claim at least 10% of OpenBSD DoS bugs are actually remotely exploitable, offer no proof, then give vague details about a paper you've supposedly submitted on a bug which isn't remotely exploitable under OpenBSD. You don't even say what piece of software this was.
Troll. That isn't what I said at all, I said if we figure, based upon experience as a security researcher for a well known respected firm, that even a small percentage of DoS conditions in *bsd is actually an exploitable condition, say 10% then we have a fairly significant amount. If you worked in the industry you would have some understanding of the amount of bugs that get reported as DoS that are actually much more, this holds especially true if the vendor found the bug.
What I actually said about OpenBSD is the truth, its a fairly secure OS, but the secure by default line is just that, a marketing line. As for the science crud you're perpetuating, the bottom line is that anyone who finds (and reports) a bug in OpenBSD has to fight the issue through to the point where the OpenBSD can't deny it, there is a reason Mark Dowd's OpenSSH exploit was called 'SSHutupTheo', so it's not a matter of science, it's the same principle behind most law firms- the average person won't fight, nolo contendere.
As for my talk, what do I give a shit if some random guy on slashdot believes me or not? I can disclose here or let your company pay thousands of dollars to hear it at blackhat, the bottom line is, if you use kerberos in openbsd, you're ownable.
I think its interesting that BSD doesn't consider DoS attacks as being a vulnerability anymore, this is especially interesting when you consider that many DoS attacks that are reported end up being remote code execution vulnerabilities that the given researcher couldn't figure out, or the vendor didn't take the time to figure out. This is especially the case with OpenBSD if you look at the CORE timeline, the OpenBSD team attempted to say remote code execution was impossible, as they did when Dowd found the OpenSSH bug, and it took a proof of concept to make them accept they had another bug.
If you cross reference DoS attacks against OpenBSDs changelog and figure that even a small amount (say 10%) of them were remotely exploitable (which is being kind), then you have a lot of remote bugs in OpenBSD and even more in FreeBSD. The fact that the vendor doesn't call them bugs just brings images of DJB to mind, but it doesn't impact the fact that your box could get owned.
What this ultimately means is that, OpenBSD is pretty good when it comes to security, but that their party line is mostly marketing hype. I just submitted a paper to a few conferences dealing with a given bug I've found, it also affects OpenBSD (but it's not a default remote root bug for them), but what it does show is how proactively secure they are, because they copy/pasted the same section of code as everyone else and missed a very obvious bug.
Actually, one thing I was quite surprised to learn while working on government networks is that many of the classified networks use the internet as a tunneling medium, but they use boxes for encryption that come from the NSA, with of course classified encryption algorithms (taclanes/kg-175).
Funny enough however, is that I worked for DOE, so you should be well aware that secure net is not a seperate network, nor is the new ESN network they're bringing up.
You are wrong. We could plainly start with the plausibility of the address being 0x61626300, i have yet to see a mapping in any OS where that would be a valid address without lots of extra mappings/etc. Your conjecture however that there is no way to know is simply untrue, you could declare another variable in.data (globaly scoped and initialized variable) and check that address, dependant on OS you could query the OS to know if it's a valid pointer, or you could check to see if its a valid address in any number of places. So as I said, this works and your conjecture that it cannot be checked is simply false.
cast a pointer to the address of foo and then do something along the lines of if (*ptr == 0x61 && *(ptr+1) == 0x62 && *(ptr+2) == 0x63 && *(ptr+3) == 0x64) ?
im humored by first telling me i was essentially stupid and that what I asked couldn't be done, and then when i respond in the same eloquence as i was addressed i have an inflated ego.
excuse me, i misphrased my question. I meant, why didnt you do what I had typed (sizeof(foo) != sizeof(char *).. if (sizeof(char *) == 4*sizeof(char)...), you had said in the second if statement if (sizeof(char *) != 4*sizeof(char), testing to see if char * was not 32-bits, I guess it makes sense, it just seemed backwards to me, but as I think about yours more it makes sense.
Also, what platform would sigsegv on accessing the memory at the address of a variable?
interesting, I'm surprised I had never thought of checking it that way. I've always just checked if at the address of 'foo' if there was abc, and if not decided it was a pointer. Yours is an interestingly obvious answer to me that had never occured to me, I will probably change the question to "abcd" to avoid it in the future, as I'm really looking to see if a person understands what a pointer is exactly, and while yours is technically correct, its not really what I was looking to test. Out of curiousity, why would you do if (sizeof(foo) != sizeof(char *)... if (sizeof(char *) == 4*sizeof(char))... else...?
They have trouble because it's a C question, not a computer science question. It's not what they studied for four years.
Indeed, although to be fair every person I interview has C/C++ on their resume, so I expect a basic understanding of such basic nuances; however overall I consider these to be generic CS questions expressed in C.
and most computer science programs don't involve enough programming for people to run across the difference between those two - many will know it, but because they've learned on their own.
Which is how we got onto this reply, the OP asked how to prepare himself the best, and I told him to learn this stuff that he won't learn in college.
Also because of this: what's the difference between these lines of code?
int main(int argc, char **argv) {... }
int main(int argc, char *argv[]) {... }
This actually made me think of another question (that is C related and not CS in general), but why x(T **arg) and x(T *arg[]) are equiv when x(...) { T **arg; } and x(...) { T *arg[] } are not; I doubt I will ever ask it because it's a more subtle nuance.
don't think I'd fault someone because of that; it's very bad code. Any sane person would use a member of the strcpy family for this (and then get the benefit of someone else having optimised the copy operation). Since this code contains a potential overrun, you need to either validate src carefully or use strncpy (if you are writing portable code) or strlcpy (if you can get away with only running on platforms with a decent libc). If a prospective employer gave me this as an example of code that I'd be likely to encounter while working for them, I'd run a mile.
It was part of a larger question, dealing with optimization actually and I gave him several strcat functions, he couldn't follow the question because he didn't really understand the nuances of nul termination (which if you took the time to look through most libc implementations of strcpy/strcat this is exactly what they do, i want coders not api monkeys). Furthermore, I like it when you programmers think that strncpy() and strlcpy() are safe, especially strlcpy()- but then again, at my last check those 'decent libc' implementations you refer to don't check that the arguments to calloc() et al are sane, go figure.
And were you writing code for embedded systems? Did the job actually require knowledge of assembly, or was it just a buzzword you liked? It's sometimes useful to have an understanding of assembly - I spent some time today reading through some compiler output to see how well it had managed to vectorise my code - but I would hardly call it an essential skill for 99% of programming jobs.
It was for a security position, so it included writing exploits (requires assembly) and reverse engineering (requires assembly most of the time), so the job is almost 100% assembly. Basically, we're the guys who rip holes in the code people like you write for a living. Agreed however, while knowing it will help every programmer, it's not something most programmers will ever use again.
Here's another question that has torn down quite a few interviewee's, tell me what principle does this demonstrate and why is it that it seems a large percentage of college grads don't understand the principle?
I didn't go to college, and yes I know they're taught, but what I've found from interviewing people for the last few years is that few people with degree's actually have really used any of it/know it, i recently interviewed a guy with a masters in CS from a fairly average US.edu who couldnt really follow some code because of this line: while (*dst++ = *src++), he could tell me what linked lists were and draw a representation of them on the board, but couldn't tell me what potential security risks there were in unlinking a member from a linked list (doubly linked was my example), and the only interviewee i've had that knew any assembly was a guy with an EE degree and ~20 years experience.
it sounds like you're just not talented at whatever it is you do; google notices if you're good at what you do, and nothing else matters, just like every other big IT firm out there.
is sit down and learn all the stuff they dont teach in (most) college(s), this means assembly, low level C, learn how traditional data structures work (i.e. linked lists/queues/et cetera without things like the STL), learn how dynamic memory allocation works, and study math study math study math. If you get good at all of the above, while college is still good and it makes you more rounded, it isn't necessary.
I wonder how this will be used (if at all), take for instance a state like California, which has routinely violated federal law by passing state laws for medicinal marijuana/etc; furthermore with things like that gathering momentum in other states (colorado? nevada? etc) it could seem in DC that certain aspects of their official line are under official attack. I wonder if it will get used for things like that, or if it would be used only in response to a natural disaster/terrorist attack/'act of god'.
Slashdot Mirror
Well your initial conjecture was that using the heap was bad, and then you proceeded to use the heap. Furthermore, are you saying that good coding practices dictate that one doesn't use the heap and instead allocates on the stack?? I think I may have misunderstood you, but I'm not sure. It's kind of absurd to presume that just because you're using new/delete or using destructors/constructors that you're in the clear, in fact heap exploitation is moving in the direction of attacking the objects themselves instead of heap metadata (although that point is largely irrelevant to the matter at hand)
Finally, there was no memory leak, the resources would be returned to the system when the program exited. While it would've been proper to deallocate the memory and then exit, it really doesn't matter if all he did was exit.
assuming your reserve() method allocates 100 bytes, where exactly do you think it gets allocated on? (answer: most likely the heap)
Regardless of what they believe it to be at the time, they patched it promptly. The label of being an issue of reliability or security, is merely to vaguely inform users of the severity. It was patched promptly and then later found to be a security issue, which the OpenBSD project publically acknowledged.
Indeed it was promptly patched and I won't attempt to take that away. My question was more in dealing with the motives of calling it reliability instead of security, and one has to wonder how many other reliability patches there are out there and if this pablumification of security patches does a greater disservice to the OpenBSD userbase ('oh its not an important patch it can wait till a stable release/monday/whatever').
What would you know the OpenBSD project ATTEMPTED to say and where did you find the word "impossible" from the OpenBSD project in this matter? Why don't we stick with what they DID say. I don't want YOUR interpretation. What they DID say, was "it would be surprising to be able to run arbitrary code".
The OpenBSD project "would be surprised", they then subsequently were surprised and promptly upgraded the status from a reliability issue, to one of security.
You are indeed correct, that was poor wording on my part and was not so much an attempt to mislead on my part but rather a case of being inarticulate. My overall point however still remains, was this a truthful impression or more egotistical blabber in an attempt to avoid admitting to another bug in the default install? And that this makes me question their firm belief in security because they put their users at risk by silently patching, redefining terms and contorting security fixes to be reliability fixes.
The "vendor" DOES consider them bugs. They just draw the distinction that the bug IS KNOWN to cause a reliability issue, but is NOT CURRENTLY ***BELIEVED*** TO BE A SECURITY ISSUE. Where "security issue" includes the running of arbitrary code and therefore potentially the gaining of remote access.
Misuse of the word on my part, I meant to say vulnerability. The fact that the OpenBSD team does not consider them a vulnerability is absolutely fucking absurd. I work as a security researcher and my company will not let us release advisories for things that are only DoS attacks, so I understand the difference but there are plenty of security implications from a DoS, even if it is not as useful or glamorous as remote code execution.
My overall point is that I can't help but wonder if the choice to not refer to it as a security vulnerability has to do with the desire to not modify the 'x bugs in x years' line.
The "party line" is a statement of fact. How you interpret it is up to you. I take it merely as a statement which reflects the ATTITUDE of the leadership behind the OpenBSD project. Anyone who took it as something more than that, probably ought to be running something else, since they clearly are not capable of understanding the significance of "secure by default". It does not mean our software is absolutely secure, it means our software installs and exposes little by default. It is a clean system for which to build upon, as opposed to a kitchen sink system to whittle down.
It's a statement of contorted facts, I've kept a fairly close eye on the changelog off and on and am aware of the number of reliability fixes in there, and I've even dug into some of them, and I will leave it at that, but it will be interesting to see how many reliability fixes come out in the IPv6 code, which is incredibly shaky (and then digging backwards how many reliability fixes have there been dealing with mbuf's? more than one, I know that).
Taking it as a sign of the attitude is absurd and thats like nike saying that their claims to not run sweatshops was covered by their first ammendment rights.
BTW, I am not the other AC you have been talking with, however I do work in the industry. Also like you (I'm assuming here), in a research capacity (expert witness) f
So you claim at least 10% of OpenBSD DoS bugs are actually remotely exploitable, offer no proof, then give vague details about a paper you've supposedly submitted on a bug which isn't remotely exploitable under OpenBSD. You don't even say what piece of software this was.
Troll. That isn't what I said at all, I said if we figure, based upon experience as a security researcher for a well known respected firm, that even a small percentage of DoS conditions in *bsd is actually an exploitable condition, say 10% then we have a fairly significant amount. If you worked in the industry you would have some understanding of the amount of bugs that get reported as DoS that are actually much more, this holds especially true if the vendor found the bug.
What I actually said about OpenBSD is the truth, its a fairly secure OS, but the secure by default line is just that, a marketing line. As for the science crud you're perpetuating, the bottom line is that anyone who finds (and reports) a bug in OpenBSD has to fight the issue through to the point where the OpenBSD can't deny it, there is a reason Mark Dowd's OpenSSH exploit was called 'SSHutupTheo', so it's not a matter of science, it's the same principle behind most law firms- the average person won't fight, nolo contendere.
As for my talk, what do I give a shit if some random guy on slashdot believes me or not? I can disclose here or let your company pay thousands of dollars to hear it at blackhat, the bottom line is, if you use kerberos in openbsd, you're ownable.
I think its interesting that BSD doesn't consider DoS attacks as being a vulnerability anymore, this is especially interesting when you consider that many DoS attacks that are reported end up being remote code execution vulnerabilities that the given researcher couldn't figure out, or the vendor didn't take the time to figure out. This is especially the case with OpenBSD if you look at the CORE timeline, the OpenBSD team attempted to say remote code execution was impossible, as they did when Dowd found the OpenSSH bug, and it took a proof of concept to make them accept they had another bug.
If you cross reference DoS attacks against OpenBSDs changelog and figure that even a small amount (say 10%) of them were remotely exploitable (which is being kind), then you have a lot of remote bugs in OpenBSD and even more in FreeBSD. The fact that the vendor doesn't call them bugs just brings images of DJB to mind, but it doesn't impact the fact that your box could get owned.
What this ultimately means is that, OpenBSD is pretty good when it comes to security, but that their party line is mostly marketing hype. I just submitted a paper to a few conferences dealing with a given bug I've found, it also affects OpenBSD (but it's not a default remote root bug for them), but what it does show is how proactively secure they are, because they copy/pasted the same section of code as everyone else and missed a very obvious bug.
I have an interesting perspective on this because I got to work in relation to these attacks for almost 2 years.
Actually, one thing I was quite surprised to learn while working on government networks is that many of the classified networks use the internet as a tunneling medium, but they use boxes for encryption that come from the NSA, with of course classified encryption algorithms (taclanes/kg-175). Funny enough however, is that I worked for DOE, so you should be well aware that secure net is not a seperate network, nor is the new ESN network they're bringing up.
At a 50-75% memory usage increase no less.
Yea and was in PaX about 6 years ago, so much for being proactively secure.
You are wrong. We could plainly start with the plausibility of the address being 0x61626300, i have yet to see a mapping in any OS where that would be a valid address without lots of extra mappings/etc. Your conjecture however that there is no way to know is simply untrue, you could declare another variable in .data (globaly scoped and initialized variable) and check that address, dependant on OS you could query the OS to know if it's a valid pointer, or you could check to see if its a valid address in any number of places. So as I said, this works and your conjecture that it cannot be checked is simply false.
Yes I just meant to 8-bits, not an 8-bit pointer; i.e. uint8_t/char/whatever
(presuming 8-bit pointer of course)
cast a pointer to the address of foo and then do something along the lines of if (*ptr == 0x61 && *(ptr+1) == 0x62 && *(ptr+2) == 0x63 && *(ptr+3) == 0x64) ?
im humored by first telling me i was essentially stupid and that what I asked couldn't be done, and then when i respond in the same eloquence as i was addressed i have an inflated ego.
excuse me, i misphrased my question. I meant, why didnt you do what I had typed (sizeof(foo) != sizeof(char *) .. if (sizeof(char *) == 4*sizeof(char) ...), you had said in the second if statement if (sizeof(char *) != 4*sizeof(char), testing to see if char * was not 32-bits, I guess it makes sense, it just seemed backwards to me, but as I think about yours more it makes sense.
Also, what platform would sigsegv on accessing the memory at the address of a variable?
i meant to say:
Quite simply, *foo will appear in memory as:
[0xaddress] --> [abc]
whereas foo[] would appear as:
[abc]
telling the difference is fairly easy (and portable), you fail, go figure.
interesting, I'm surprised I had never thought of checking it that way. I've always just checked if at the address of 'foo' if there was abc, and if not decided it was a pointer. Yours is an interestingly obvious answer to me that had never occured to me, I will probably change the question to "abcd" to avoid it in the future, as I'm really looking to see if a person understands what a pointer is exactly, and while yours is technically correct, its not really what I was looking to test. Out of curiousity, why would you do if (sizeof(foo) != sizeof(char *) ... if (sizeof(char *) == 4*sizeof(char)) ... else ...?
sorry, you're wrong. Quite simply, *foo will appear in memory as:
[0xaddress] --> [abc]
[abc]
So you'd simply check whats at the address of foo, if it isn't abc or similar (dependant on endianness), then its a pointer.
They have trouble because it's a C question, not a computer science question. It's not what they studied for four years.
... } ... }
Indeed, although to be fair every person I interview has C/C++ on their resume, so I expect a basic understanding of such basic nuances; however overall I consider these to be generic CS questions expressed in C.
and most computer science programs don't involve enough programming for people to run across the difference between those two - many will know it, but because they've learned on their own.
Which is how we got onto this reply, the OP asked how to prepare himself the best, and I told him to learn this stuff that he won't learn in college.
Also because of this: what's the difference between these lines of code?
int main(int argc, char **argv) {
int main(int argc, char *argv[]) {
This actually made me think of another question (that is C related and not CS in general), but why x(T **arg) and x(T *arg[]) are equiv when x(...) { T **arg; } and x(...) { T *arg[] } are not; I doubt I will ever ask it because it's a more subtle nuance.
don't think I'd fault someone because of that; it's very bad code. Any sane person would use a member of the strcpy family for this (and then get the benefit of someone else having optimised the copy operation). Since this code contains a potential overrun, you need to either validate src carefully or use strncpy (if you are writing portable code) or strlcpy (if you can get away with only running on platforms with a decent libc). If a prospective employer gave me this as an example of code that I'd be likely to encounter while working for them, I'd run a mile.
It was part of a larger question, dealing with optimization actually and I gave him several strcat functions, he couldn't follow the question because he didn't really understand the nuances of nul termination (which if you took the time to look through most libc implementations of strcpy/strcat this is exactly what they do, i want coders not api monkeys). Furthermore, I like it when you programmers think that strncpy() and strlcpy() are safe, especially strlcpy()- but then again, at my last check those 'decent libc' implementations you refer to don't check that the arguments to calloc() et al are sane, go figure.
And were you writing code for embedded systems? Did the job actually require knowledge of assembly, or was it just a buzzword you liked? It's sometimes useful to have an understanding of assembly - I spent some time today reading through some compiler output to see how well it had managed to vectorise my code - but I would hardly call it an essential skill for 99% of programming jobs.
It was for a security position, so it included writing exploits (requires assembly) and reverse engineering (requires assembly most of the time), so the job is almost 100% assembly. Basically, we're the guys who rip holes in the code people like you write for a living. Agreed however, while knowing it will help every programmer, it's not something most programmers will ever use again.
Here's another question that has torn down quite a few interviewee's, tell me what principle does this demonstrate and why is it that it seems a large percentage of college grads don't understand the principle?
header_0.h: char *foo = "abc";
header_1.h: char foo[] = "abc";
Presume one and only one of these header files is included in a program, write a routine that can determine which one was included (at runtime).
It's not a hard question at all, but neither are any of the questions I ask.
I didn't go to college, and yes I know they're taught, but what I've found from interviewing people for the last few years is that few people with degree's actually have really used any of it/know it, i recently interviewed a guy with a masters in CS from a fairly average US .edu who couldnt really follow some code because of this line: while (*dst++ = *src++), he could tell me what linked lists were and draw a representation of them on the board, but couldn't tell me what potential security risks there were in unlinking a member from a linked list (doubly linked was my example), and the only interviewee i've had that knew any assembly was a guy with an EE degree and ~20 years experience.
it sounds like you're just not talented at whatever it is you do; google notices if you're good at what you do, and nothing else matters, just like every other big IT firm out there.
is sit down and learn all the stuff they dont teach in (most) college(s), this means assembly, low level C, learn how traditional data structures work (i.e. linked lists/queues/et cetera without things like the STL), learn how dynamic memory allocation works, and study math study math study math. If you get good at all of the above, while college is still good and it makes you more rounded, it isn't necessary.
I wonder how this will be used (if at all), take for instance a state like California, which has routinely violated federal law by passing state laws for medicinal marijuana/etc; furthermore with things like that gathering momentum in other states (colorado? nevada? etc) it could seem in DC that certain aspects of their official line are under official attack. I wonder if it will get used for things like that, or if it would be used only in response to a natural disaster/terrorist attack/'act of god'.
indeed, the framers out of the bill of rights recognized two forms of a citizens vote.