flawfinder for AmigaOS 4

Hello everyone.
I want to let you all know that today I prepared a release of Flawfinder 2.0.19 for the AmigaOS 4. Flawfinder is a tool for developers, and as the author mentions:

Quote:

Inside the archive, you will find the documentation in HTML and pdf. Flawfinder is a python script but it should be able to execute it as a plain command from anywhere, as long as it is in your path, or by providing its full location.

The very basic way to use it is:
flawfinder src/

There is a way to generate the findings in HTML format as well. Have a look at the documentation.

You can find it at https://git.walkero.gr/walkero/flawfin ... leases/tag/2.0.19r1-amiga and soon on OS4Depot.

Please, let me know what do you think of it and if you find such tools useful.

@walkero

thx for such tool.
Just tested on a few sources I have and showed tons of warnings X-)

Thanks Walkero. This could be really handy!

@walkero

Uuuuh, neat.
Will test asap, thanks a lot.

Since we can't get the sanitizers https://github.com/google/sanitizers this is the bext best thing...

Glad you like it.
I am working on the https://cppcheck.sourceforge.io/ which I have already somewhat working, but I get a crash, which I am trying to fix before it is able to be released. This is much bigger than Flawfinder and a much more complete tool. Hope I will make it work soon.

@walkero

So far it appears to me that Flawfinder mainly registers the use of C library functions that may potentially be dangerous, rather than scan for actual vulnerabilities caused by one's improper programming. So it reports about code safety in a rather general way, in effect working more like a C programming reference book than a true diagnostic tool.

Some of the warnings I find debatable. For example, Flawfinder will warn you about every use of strlen(), telling you that the function isn't safe when used on a string that has no terminating NUL character. But that's a bogus report IMHO because, first, if it has no NUL at the end it's not a C string - so why would I use strlen() to determine the length of it? -, and second, what other method does the Flawfinder author recommend if not strlen()? Am I supposed to keep string lengths in separate variables or what?

At any rate, it's great to have another tool in the programmer's arsenal. Better rule out a hundred false positives than overlook one real problem!

George, thank you for porting this. I've said it before and I'll say it again: you're a true asset to the Amiga community!

From reading the documentation, Flawfinder seems to be mainly oriented toward finding security flaws in applications that are going to be under attack by someone trying to compromise them for malicious purposes. An unterminated string is just the sort of thing such an attacker might use, so Flawfinder is correct to report strlen() as a potential security flaw. Perhaps "SecurityFlawfinder" would be a better name.

I ran Flawfinder on one of my programs, and it complained a lot about strlen(), memcpy(), strncpy(), and the like, all things where buffer overflows are possible if misused. I always guard against such errors when writing a program, so the value of Flawfinder for me is minimal. It might be more helpful when using someone else's code, where the author(s) might not be as careful about such things as I am.

One annoyance I noticed: I tend to keep older versions of my programs in subdirectories of the project directory. Pointing Flawfinder at the project directory caused it to recurse into all the historical versions of the code as well as the current version, repeating the same warnings over and over for every different version. There doesn't seem to be an option to turn directory recursion off.

I don't know if Flawfinder is going to become one of my regular tools or not. But I appreciate walkero's work on bringing it to the Amiga-- better to have a tool and decide not to use it, than to not have it at all.

What we need is a good Lint for the Amiga. I look forward to Cppcheck, which appears to do at least some of what Lint does.

This kind of application that checks the source code, without being able to watch it while it runs, is only for recommending places for possible issues. It is not to follow their recommendations blindly. A better solution would be something that compiles with your app and watches all the time for possible problems like memory leaks etc. As much as I understand such a program is Valgrind, but I am not sure if it is possible to be ported.

I agree with msteed, it is good to have such tools available, even if people choose to not use them. Flawfinder and cppcheck are both tools that are used at codacy.com which is a tool for code quality testing. That's why I am working to port them both.

cppcheck is much more complete than Flawfinder and will provide much more information.

cppcheck port is done and seems to work quite well, but unfortunately I can't release it yet, although I'd love to. The reason is that it requires a newer version of newlib 53.73 or higher. As soon as this is released, I will make cppcheck available.

Now I am trying to compile it with clib2, but I have some issues with it. If this works in the end, I might release it.

@walkero

Are you using Andrea's clib2?

@flash

Yes... I found some ways to fix some issues. I am optimistic that this could work with clib2 fine.

If you find something wrong in clib2 please open an issue

@msteed

Quote:

No a none terminated string will most likely crash your computer, or make your code run extremely slowly, in the best case.. if program is not working, it just not likely it will be exploited.

buffer overruns come from pre-allocated buffers. Something like



Now with this code someone can type password longer then 30 char, and scanf will change “success”. scanf does not know the size of tmp buffer, don't care if there is 0 in tmp, as it will be overwritten.

I compiled cppcheck with afxgroup clib2 but I am getting the following errors by the linker. Any ideas?

@walkero

it's a function that has no arguments, that returns "_impure_ptr".

https://github.com/eblot/newlib/blob/m ... lib/libc/reent/getreent.c

silly _DEFUN_VOID macro is here:

https://github.com/msysgit/msys/blob/m ... wlib/libc/include/_ansi.h

in case like know what "_impure_ptr" is.

https://embdev.net/topic/what-is-_impure_ptr

@liveforit
Thank you for your reply. This seems to be missed from clib2. I will let afxgroup know.

update:
Actually I saw that kas1e reported the same thing at https://github.com/afxgroup/clib2/issues/53
So, we will see how it goes, but if I understand correctly, this is not possible yet.

@LiveForIt

Quote:
That's true if the unterminated string comes from within the program, as the result of a programmer error. But Flawfinder is looking for problems that come from outside the program, such as data that's read over a network, or files that are downloaded from somewhere.

Web browsers, streaming audio and video players, and any kind of file viewer or editor that operates on files created by someone else are examples of vulnerable programs. In such cases the attacker can try to exploit buffer overflows by creating a data file that's deliberately corrupted in a way that might trigger an overflow.

For example, if a particular file format dictates that a certain string stored in the file will never be longer than 'x' characters, then perhaps a program that's parsing that file will try to read the string into a buffer that's only 'x' characters long. If strlen()/memcpy() or strcpy() are used to read the string into the buffer, then a string that's longer than is legal may result in the buffer overflowing, as in your example.

To be safe, you need to make sure the length that is copied is clipped to the size of the buffer, something that strlen() and strcpy() don't do. That's what Flawfinder is pointing out-- it's reminding you to keep in mind how your program will respond to corrupted data.

If your program isn't operating on data from the outside world, then Flawfinder will likely not be of much use. Though I think it's worthwhile to keep buffer overflows in mind even when just reading files your program has written-- it's always possible for a file to accidentally get corrupted, and it's better for your program to safely reject such a file than to blow up when it tries to read it.

@msteed

Quote:

well strlen() is not used to write strings into buffer, and how the buffer is declared that’s the problem, memcpy is not meant for string operating in general, as the name suggest meant for copy memory.

Yes strcpy is dangers, as does have destination max length as argument. Strncpy should be used instead,
like sprintf is unsafe, while snprintf is safe.

Strcat() is also a unsafe function, as strcat again does not know the length of designation buffer, not how many bytes its filled before.

@walkero

You are linking against newlib listdc++.a that's why you get those undefined functions (/gcc/lib/libstdc++.a). Most porbably you have missed -mcrt=clib2 in LDFLAGS or something

@afxgroup
No, I use -mcrt=clib2 with linker as well. Here is the full linker command and the error.

so /gcc/lib/libstdc++.a is the clib2 version? It is strange.. even because __errno is a newlib function and not a clib2 one. That's why I suspect you are mixing the two libs