Re: Interfaces to limit string sizes
Paulo Roberto <[email protected]>
| Newsgroups | gmane.linux.drivers.gammu |
|---|---|
| Message-ID | <CA+96iqdAa=ioEFCiYTtVZ7tJ3bR+Q_yMhFNkLd5Aq3A4pQYyXQ@mail.gmail.com> |
Hi Michal, I understand that checking definitions in .h files looking for size increase the chances to code safely, but is not the advisable way to do things, specially in a public API. The current implementation violates memory safety, allowing Buffer overflow when misused, that is a serious security issue. C is vulnerable and there are a lot of Security Principles and Rules regarding to robust and secure coding: https://www.securecoding.cert.org/confluence/display/c/SEI+CERT+C+Coding+Standard Trusting on the user input is a violation of this principles. It's not defensive driving, it's not according to the least privileged principle and also the fact that your software should not crash when receiving unexpected input. There are also rules that it breaks, among then: 0 - Enforce Input compliance 1 - Use SAFE string function That is why we should not use strcpy anymore and should use only strncpy or better yet strlcpy. libc provide both type of functions, the safe ones and the others for compliance, but good practices says that we should use only the former. I understand the maintainability issue to have 2 functions doing the same thing, but it could be a transitory measure to use only safe routines. If you prefer, I could correct the current ones, but it could break current software that use your library. It was just some thoughts in the matter, I wait for your decision and if I could help in anything I would be glad in doing so. Thanks again for your time. Kind Regards. Paulo Roberto Brandão. On Tue, Mar 22, 2016 at 5:13 AM, Michal Čihař <[email protected]> wrote: > Hi > > Dne 21.3.2016 v 23:08 Paulo Roberto napsal(a): > > I've been using LibGammu in some projects, it's a great project. > > > > But I noticed that dealing with strings could be a lot error prone and > > if not careful you could have some security issues. > > I say this because of the use of static string variables and the > > assumption of correctness in the buffer size. > > Indeed it does. The buffer sizes are exported as well in gammu-limits.h. > > > To solve it in my projects I implemented some new interfaces for the > > functions that I use. Mainly in coding.c and api.c. > > > > The new functions do the same of the old ones, but add the control of > > limit buffers size. I was not sure about how to name the new functions, > > so I added a '_s' in the name of the old functions. > > > > Example: > > CopyUnicodeString => CopyUnicodeString_s > > > > I'm sending a little patch with these changes. If you approve the > > modification, I would be glad to add equivalent functions for the rest > > of the API when it requires. > > I'm not really sure if it's good idea to add second set of API, > especially as your changes basically duplicate existing code, what will > make it really easy to fix only one copy of it in future... > > -- > Michal Čihař | http://cihar.com/ | https://weblate.org/ > > > > ------------------------------------------------------------------------------ > Transform Data into Opportunity. > Accelerate data analysis in your applications with > Intel Data Analytics Acceleration Library. > Click to learn more. > http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140 > _______________________________________________ > Gammu-users mailing list - > https://lists.sourceforge.net/lists/listinfo/gammu-users > > ------------------------------------------------------------------------------ Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140 _______________________________________________ Gammu-users mailing list - https://lists.sourceforge.net/lists/listinfo/gammu-users