On Fri, Jun 21, 2013 at 4:11 PM, Marcus D. Leech <mle...@ripnet.com> wrote: >> On Fri, Jun 21, 2013 at 3:39 PM, Tom Rondeau<t...@trondeau.com> wrote: >>> >>> On Fri, Jun 21, 2013 at 12:41 PM, Marcus D. Leech<mle...@ripnet.com> >>> wrote: >>>> >>>> There are safe uses for unconstrained string functions. Just, well, not >>>> very many... >>>> >>>> -- >>>> Marcus Leech >>> >>> No. Never, ever, ever is it ok. I say this using a strlen call now... >>> (but it's against strings that are hard-coded into our files by us, so >>> if that breaks, we have only ourselves to blame). >>> >>> Also, just pushed a fix. This should take care of things. >>> >>> Tom >> >> Pardon my ignorance here, but would someone mind explaining this a >> little more? My intuition is saying that it's unsafe to use strcmp on >> user input because there's no checking that there is in fact a sane >> string (null terminated), but I haven't been around long enough to be >> sure that's the issue or if there's just something more sensible in >> boost. >> >> I'd be happy with a link on the topic; I couldn't find anything useful >> googling. >> >> -Nathan >> > The standard C string functions (the unconstrained ones) are well-known to > be unsafe, and a rich source of buffer-overrun bugs/attacks in the > last couple of decades. > > Still, it's so much more convenient to type strcmp (a,b) rather than strncmp > (a,b,l), etc, etc. > > So, sometimes you slip up and use the "unsafe" version. > > -- > Marcus Leech > Principal Investigator > Shirleys Bay Radio Astronomy Consortium > http://www.sbrac.org
Yeah. Basically, you can send a string of any length and strcmp will attempt to read it, which is what can lead to the buffer overrun. Another problem, aside from laziness as Marcus says, is that you don't often know the correct value for 'l'. It's just as suspect to strlen(a) for some random string a. In this case, I /know/ that string b is properly terminated (because I wrote it into the code). So I use the length of b to compare with a and l = strlen(b). There are other ways, too, but this was the most unobtrusive way to handle this case. Tom _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
