|
How secure is Allego? |
Emanresu
Member #12,510
January 2011
|
While looking up information about secure coding practices, I came across a few articles that recommend you avoid a bunch of different standard functions due to some security flaws that they have. In the PDF below, they give a list of functions to avoid. http://www.safecode.org/publications/SAFECode_Dev_Practices1108.pdf said: Function Families to Remove:
Which brings me to the main question, how secure is Allegro? "* Entoutcas has quit IRC (Quit: And the Lord said unto John; Come forth and receive eternal life. But John came fifth and won a toaster...)" |
Elias
Member #358
May 2000
|
Allegro's string functions use bstrlib internally and so should be completely "safe". [edit:] hm, it seems the docs on allegro.cc don't handle unicode chars, linking to liballeg docs instead (it seems to be a bug in firefox though) -- |
torhu
Member #2,727
September 2002
|
Those functions are only "insecure" if you use them in the wrong way, with the exception of gets, which is as good as always a bad idea to use. The real problem with them is that it is easier to use them the wrong way than the right way, and that using them the wrong way can open your code to buffer overflow attacks. |
Matthew Leverton
Supreme Loser
January 1999
|
Allegro relies on external libraries like libpng, GDI+, etc to be secure. If any of those have bugs, then Allegro will have bugs. On top of that, Allegro's own code could have security related bugs. e.g., I doubt every al_malloc() is checked to see if it is non NULL. Then there's user code. If I supply your program with an invalid bitmap, and Allegro returns NULL, and you do nothing about it, then your program will crash. If Allegro were built with security as a primary focus, then every function would check for NULL pointers, etc. But that's your responsibility. If a user provided a 1000MB allegro.cfg file, then Allegro would probably choke while trying to load the config file. For Allegro's intended purpose, stuff like that doesn't really matter. But if you are running Allegro as part of some online image processing service, then some of these things come into play. PS: This is, of course, not an exhaustive list. I'm just pointing out that there are many ways to crash a program that doesn't technically have bugs. |
raynebc
Member #11,908
May 2010
|
If failing to validate input and output leads to a crash, I consider it a bug. It reminds me of this time I was dealing with a laptop manufacturer about a blue screen of death that would occur every time a data logging application my company uses made a particular modem API call. The support got escalated to some customer representative that handled our region of the USA. He kept arguing (wrongly) that it was a bug in the application based on the evidence that was the software that was running when the BSOD occurred. I countered (correctly) that it was a driver bug because a user application shouldn't have the level of system access necessary to crash the OS and the application worked on every other laptop and desktop computer that was made by another manufacturer. I even got the application's developer in touch with the rep, who confirmed that he'd come to notice that Conexant modems used in various different laptops were prone to crashing in this way. I'd gotten on the rep's case enough that eventually the company's engineers released a driver update to address it, although they had the gall to indicate in the release notes that it was to address a crash that occurred when using the data logging application in question. At that point, they can't save face even though they'd like to pretend it wasn't their bad programming at fault. |
Matthew Leverton
Supreme Loser
January 1999
|
Validating user's input is generally a waste of time in the context of Allegro. Failing to check the return value of malloc would be a bug. |
Elias
Member #358
May 2000
|
Validating user input doesn't help, e.g. if you look at the 'safe' string functions you can still pass invalid pointers. -- |
bamccaig
Member #7,536
July 2006
|
Sometimes it's appropriate to code defensively and constantly check the validity of arguments at every step along the stack, but that will weigh-in on performance. If performance isn't a concern of yours then you're probably doing it wrong coding in C in the first place. -- acc.js | al4anim - Allegro 4 Animation library | Allegro 5 VS/NuGet Guide | Allegro.cc Mockup | Allegro.cc <code> Tag | Allegro 4 Timer Example (w/ Semaphores) | Allegro 5 "Winpkg" (MSVC readme) | Bambot | Blog | C++ STL Container Flowchart | Castopulence Software | Check Return Values | Derail? | Is This A Discussion? Flow Chart | Filesystem Hierarchy Standard | Clean Code Talks - Global State and Singletons | How To Use Header Files | GNU/Linux (Debian, Fedora, Gentoo) | rot (rot13, rot47, rotN) | Streaming |
Emanresu
Member #12,510
January 2011
|
bamccaig said: If performance isn't a concern of yours then you're probably doing it wrong coding in C in the first place. It may be wrong, but it is really the only thing I know. My knowledge of C and C++ and the code I write can be summed up in two words: Hacked Together. I failed my college C course, (I dropped out ), but feel I've learned enough to get by. And C++, well, that was "taught" to me by some friends and glances through a book to two, which bored me to tears practically. I can't tell the difference between C and C++ code, and really, I don't care either way. With security in mind, the less holes in the code, the better. "* Entoutcas has quit IRC (Quit: And the Lord said unto John; Come forth and receive eternal life. But John came fifth and won a toaster...)" |
weapon_S
Member #7,859
October 2006
|
I just discovered loading functions do not check for a null as filename argument. I was more surprised to see a libc function causing it (strrchr); contrary to a bstrlib, like mentioned here. Won't cause overrun, but it's funny nevertheless. |
SiegeLord
Member #7,827
October 2006
|
Use the debug version of the library if you want the extra checks. Once they all pass, switch to the release version for performance. "For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18 |
|