Allegro.cc - Online Community

Allegro.cc Forums » Programming Questions » How secure is Allego?

This thread is locked; no one can reply to it. rss feed Print
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:

  • strcpy family

  • strncpy family

  • strcat family

  • strncat family

  • scanf family

  • sprint family

  • gets family

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...)"
"I was in a casino, minding my own business, and this guy came up to me and said, 'You're gonna have to move. You're blocking a fire exit.' As though if there was a fire, I wasn't gonna run. If you're flammable and have legs, you are never blocking a fire exit... ...Unless you're a table."
-Mitch Hedberg (R.I.P.)
"Quit: (+[WG]sPiKie) (Math problems? Call 1-800-[(10x)(13i)^2]-[sin(xy)/2.362x].)"

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)

--
"Either help out or stop whining" - Evert

torhu
Member #2,727
September 2002
avatar

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
avatar

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
avatar

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.

--
"Either help out or stop whining" - Evert

bamccaig
Member #7,536
July 2006
avatar

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. :)

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 ;D), 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...)"
"I was in a casino, minding my own business, and this guy came up to me and said, 'You're gonna have to move. You're blocking a fire exit.' As though if there was a fire, I wasn't gonna run. If you're flammable and have legs, you are never blocking a fire exit... ...Unless you're a table."
-Mitch Hedberg (R.I.P.)
"Quit: (+[WG]sPiKie) (Math problems? Call 1-800-[(10x)(13i)^2]-[sin(xy)/2.362x].)"

weapon_S
Member #7,859
October 2006
avatar

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. :P

SiegeLord
Member #7,827
October 2006
avatar

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
[SiegeLord's Abode][Codes]:[DAllegro5]:[RustAllegro]

Go to: