Just committed this change: *Changed:* *IupGetText* pre-defined dialog function API to include the maximum string size.
Best, Scuri On Mon, May 16, 2011 at 4:55 PM, Antonio Scuri <[email protected]> wrote: > Yes, I know. I thought about those functions, but I always try to avoid > polluting the iup.h header. > > The limits are now documented, but old application will still be unsafe. > Maybe in this case we should break compatibility. > > Best, > scuri > > > -----Original Message----- > > From: Jeremy Cowgar [mailto:[email protected]] > > Sent: sexta-feira, 13 de maio de 2011 19:04 > > To: [email protected] > > Subject: Re: [Iup-users] Security Hole in IupGetParam? > > > > Scuri, > > > > While that'll work, it's not ideal. To be safe one must know this and > > always allocate 10k of memory to use IupGetText, for example. I wonder > > if it wouldn't be better to introduce two new methods and deprecate the > > old unsafe ones. They are indeed unsafe and shouldn't be used by anyone. > > The suggested fix improves the situation but does not fix it. > > > > What if you were to do: > > > > char *IupGetTextSafe(const char *title, char *text, int buffer_size) { > ... } > > #define IupGetText(x,y) IupGetTextSafe(x,y,10240) > > > > and something similar for IupGetFile. This would allow for both the > > ideal solution and backward compatability with a little added safety. It > > would also highlight the security hole so that people will update their > > code to the safe alternatives. It's enough of a security hole that those > > using the function now should indeed update their code. If it is not > > adequately brought to their attention, they may continue on with huge > > security breaches in their applications. > > > > I actually think this is important enough to warrant an API break. > > Buffer over runs are nothing to play around with. Another possible > > solution would be to do the above but put the IupGetText macro in an > ifdef: > > > > #ifdef IUP_ALLOW_UNSAFE > > #define IupGetText(x,y) .... > > #endif > > > > So, their code ceases to compile and they can make the choice about how > > safe they wish to be when going to look why it broke. Now, where both of > > these solutions would break down would be if they didn't recompile their > > apps but used new .dll's on Windows. Is that even possible? Again even > > if so, people should cease using the unsafe variants right away. > > > > Jeremy Cowgar > > > > On 5/13/2011 9:06 AM, Antonio Scuri wrote: > > > Yes, they do. The ideal would be to change the API, but they are > very > > > simple methods to break compatibility. So I add internal limitations > and > > > documented them. 4096 for IupGetFile and 10240 for IupGetText. > > > > > > If MAXSTR is not used, IupGetParam will use the same limitations. > > > > > > > -------------------------------------------------------------------------- > ---- > > Achieve unprecedented app performance and reliability > > What every C/C++ and Fortran developer should know. > > Learn how Intel has extended the reach of its next-generation tools > > to help boost performance applications - inlcuding clusters. > > http://p.sf.net/sfu/intel-dev2devmay > > _______________________________________________ > > Iup-users mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/iup-users >
------------------------------------------------------------------------------
_______________________________________________ Iup-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/iup-users
