Contributed by jose on from the in-print-only dept.
(Comments are closed)
OpenBSD Journal
Contributed by jose on from the in-print-only dept.
(Comments are closed)
Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]
By Sacha () on
By Chad Loder () on
Comments
By ak () ak@synflood.at on http://synflood.at/blog/
By kris () on
Comments
By Chris Laverdure () on
OpenBSD won this by chance, all coincidence!
[/sarcasm]
Comments
By kris () on
By veins () chehad_g@epitech.net on http://etud.epita.fr/~chehad_g/
that's exactly what i was going to write.
flawfinder only checks if a function is called and not in what context it was called. using strcpy() does not make a program insecure if used properly but flawfinder will report it as a potential vulnerability.
Comments
By Damien () on
For example i know that pkg-config use strcpy() without checking the values. If i don't have the time to check the context my only choice would be to take an alternative that use strl*() functions.
Comments
By veins () chehad_g@epitech.net on http://etud.epita.fr/~chehad_g/
I dont agree, it is as easy to use strl{cat,cpy} unsafely as to use str{cpy,cat}, these functions does not make the code secure because they are called.
it is just that people who use them are usually aware of security concerns and write code with care.
Comments
By Anonymous Coward () on
Please show me the code.
Comments
By krh () on
Comments
By Damien () on
If you set your buffer size with an incorrect value, you can't blame strl*() functions for that. A good coder will use the system max lenght to size the buffer (for example MAXPATHLEN or PATH_MAX).
The str*() functions are unsafe because if the string is greater than the buffer it overflow on something else.
The strn*() functions are a bit better because they ensure that the result will fit in the buffer but it doesn't null terminate the string. So you can get a non terminated string as a result which is not safer too.
The strl*() functions make your string fitting in your buffer and null terminate it whatever the size of your string. This is safe.
The conclusion is that when i have two programs, one written with str*() and the other written with strl*(), i will assume that the second is safer than the first.
Yes, you can tell me that the second could be full of holes even if using strl*(). I'll answer you that this is the second stage of the analysis of the program.
But the more important is the following question: did you look at the code of the programs you use ?
I take again the example of pkg-config which is widely used, do you trust the following code:
if (name)
con->appName = strcpy(malloc(strlen(name) + 1), name);
I hope you're not. But it think you must have this installed somewhere on your computer(s) ...
Comments
By krh () on
We speak about secure programming. I stand by my statement.
Comments
By Damien () on
Also secure programming means avoiding the use of suid root.
By veins () chehad_g@epitech.net on http://etud.epita.fr/~chehad_g/
what i meant was that strl* could be used unsafely due to a programming error, just as str* could be used safely after appropriate checks. flawfinder could say a code is insecure even if str* was used safely and could say a code is secure even if strl* were used unsafely, relying on that for an audit is not sufficient. but surely, it gives a global idea on how secure the code is, as people using strl* are more likely to be informed about security issues related to improper bounds check.
By double-p () pb@ on mailto:pb@
sure..
sidenote: the author of said article *explicitly*
states, that this is a somewhat flawed analysis
and needs additional research of the found "bugs".
Tho I am baffeled, where that 1 strncpy is hidden :) ..
ciao
Comments
By Anonymous Coward () on
reports things all over the place,
wc -l says 216 in all.
there's a bunch more in /usr/src as a whole
but i don't hold the obsd team responsible for
all of those (e.g. the crapload in gcc's src)
Comments
By Ben () mouring@eviladmin.org on mailto:mouring@eviladmin.org
strcpy() are far worse.
By Anonymous Hero () on
It doesn't run on Your os. Perhaps you can port it or use a Real development os? If you felt offended because of the latter comment, you are emotionaly attached to your os. Use the best os for the best job!
Comments
By krh () on
By Marc Espie () espie@openbsd.org on mailto:espie@openbsd.org
You probably don't know it, but we have other tools that other unices don't have. Some of the stuff in our malloc, for instance. Or generalized propolice. Or W^X...
Yep, valgrind would be nice too. Why don't you port it instead of trolling ?