Hi John I do not have a real example of an actual attack. No.
Your comment that I have to show a actual attack on vanilla OpenOCD is fair. And yes, developer has to take responsibility to ensure his contribution doesn’t introduce any vulnerability. It is a perfectly valid stand to put responsibility to developer to ensure the safety of his work. I am perfectly happy with that. I actually take this as an important principle. I will back it up with asking reviewers to review contribution for vulnerability. Even better if there are automated test that will catch these out But taking a step back from the question of principles, there is a few other points to consider, which I unfortunately did not make it clear in my first email. It all boils down to cost/benefit analysis: How much work is too much work to help developer to help them make their code less vulnerable? (1) If it is easy to catch such an error, should we do that? In this case by simply testing for strlen(buffer) == len in jim_getopt_string(*goi, *buffer ,* len) we will catch a lot of such cases. Is it worthwhile doing that? (2) Most newbies to openocd, e.g. me, actually search for similar examples from the source code to copy when I am creating new command. For this “jtag newtap” command is one of the top choice because it is one that we are familiar with, and is complex enough that most of what we want to implement will be covered by it. When we do, we go down the jim_getopt_string() route. I cannot see us going down the jim.c hashmap approach which is more secure. Some, like me, would not had realize this potential vulnerability when we started. It’s not that we want to do vulnerable code, just that we are not aware of all attack vectors. If we want to help them, may be an extra section in openocd’s docs explaining the vulnerability and how to avoid it is suffice. (3) Initially, even after it was pointed out to me that I have to check for NULL byte attack, I said it is not quite possible: (1) OpenOCD used jimtcl as TCL parser, jimtcl folks would had taken care of that. Failing that, OpenOCD will protect me. After all, I used a OpenOCD function jim_getopt_string() to parse my command. It’s only when I set out to prove these doubters wrong that I discover this potential for bad code to be written. Perhaps I am naïve, but unfortunately I am not the only one. We can only do so much so where do we draw the line? HTH Cinly From: John S <[email protected]> Sent: Monday, July 19, 2021 3:34 PM To: Ooi, Cinly <[email protected]> Subject: Re: Potential NULL byte injection What do you mean by "a developer create these two commands in OpenOCD"? If someone adds such commands it's THEIR problem to use appropriate care. You need to provide an actual attack based on OpenOCD as it is, not as it might be changed by a careless person. Regards, John
