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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.