fopen_s
in [Visual C]
|
From: William DePalo [MVP VC++] on 28 Jun 2006 11:38 "mzdude" <jsanga(a)cox.net> wrote in message news:1151502556.372579.109710(a)j72g2000cwa.googlegroups.com... > Perhaps thread safety issue? Thread 1 opens the file and fails. > Switched out. Thread 2 runs, overwrites errno. Thread 1 then resumes > and checks errno? > > Just guessing on my part. I know you said it was just a guess, but for the benefit of the lurkers I'll point out that it is not so. All of the static global data defined by the old C runtime library is instanced on a per-thread basis provided that you link with a multi-threaded runtime library. Regards, Will
From: Carl Daniel [VC++ MVP] on 28 Jun 2006 13:39 "Eugene Gershnik" <gershnik(a)hotmail.com> wrote in message news:uoK8rBtmGHA.2372(a)TK2MSFTNGP04.phx.gbl... > David Webber wrote: >> Maybe fopen_s is not really needed for >> security > > Well that's exactly what MSDN says. It is supposed to improve error > reporting. However, improving reporting is described as security > enhancement... Probably some marketroid drunk more than usual while > writing this. ;-) Actually, it follows directly from studies of security vulnerabilities. Not checking error codes is a major source of security vulnerabilities. Having inconsistent ways of returning error codes is a major source of error codes not being checked. -cd
From: Eugene Gershnik on 28 Jun 2006 21:01 "Carl Daniel [VC++ MVP]" <cpdaniel_remove_this_and_nospam(a)mvps.org.nospam> wrote in message news:uKn6cltmGHA.3352(a)TK2MSFTNGP02.phx.gbl... > "Eugene Gershnik" <gershnik(a)hotmail.com> wrote in message > news:uoK8rBtmGHA.2372(a)TK2MSFTNGP04.phx.gbl... >> David Webber wrote: >>> Maybe fopen_s is not really needed for >>> security >> >> Well that's exactly what MSDN says. It is supposed to improve error >> reporting. However, improving reporting is described as security >> enhancement... Probably some marketroid drunk more than usual while >> writing this. ;-) > > Actually, it follows directly from studies of security vulnerabilities. > Not checking error codes is a major source of security vulnerabilities. Ok. > Having inconsistent ways of returning error codes is a major source of > error codes not being checked. I don't think it is true. COM had "everything returns HRESULT" policy since the beginning and how much COM code does actually check all of them? The major source of error codes not being checked is that programmers are not punished for doing it. There is nothing MS can do about it. -- Eugene http://www.gershnik.com
From: Norman Bullen on 28 Jun 2006 21:16 David Webber wrote: > "Eugene Gershnik" <gershnik(a)hotmail.com> wrote in message > news:O$6HiHnmGHA.464(a)TK2MSFTNGP05.phx.gbl... > > >>How returning errno helps with error reporting and what this has to do >>with security as such is beyond my imagination. Presumably somebody at >>Microsoft has trouble understanding and using an API that doesn't >>uniformly return error codes in COM manner. > > > I think we're in danger of taking this too literally in too isolated a case. > The new ...._s APIs which fill buffers (like strcpy_s) do improve security - > IIRC the debug version asserts if you try and overfill the buffer. Maybe > fopen_s is not really needed for security but is just there to complete the > set? (Personally I find the new ones - and all the warnings you get if you > don't use them - a pain.) > > Dave The _s may provide some "security" (I would call it simply bounds checking--it's not a security issue unless there's some way an attacker can leverage an array overflow in any particular case) but only if you use them properly. The following code fragment comes from the WALKALL example on MSDN. While it doesn't use the _s functions, the function StringCchPrintf() is intended to provide the same sort of protection against buffer overflows--but only if you use it correctly. // CODE REVIEW: Replace Banned API. // wsprintf(szBuff, "CWinSink refcount increased to %d\n", m_dwRef+1); StringCchPrintf(szBuff, 255, "CWinSink refcount increased to %d\n", m_dwRef+1); Note that a constant 255 is passed as the buffer size. Who knows what the _real_ buffer size is going to be after two or three maintenance programmers have worked on it? Obviously, the right was to use the function is to use a compile-time expression that is guaranteed to evaluate to the buffer size no matter what changes are made: StringCchPrintf(szBuff, sizeof szBuff, "CWinSink refcount increased to %d\n", m_dwRef+1); or, if you may need Unicode portability: StringCchPrintf(szBuff, sizeof szBuff/sizeof (TCHAR), "CWinSink refcount increased to %d\n", m_dwRef+1); By the way, the MSDN page for StringCchPrintf() has an even worse example of how to use the function. Norm -- -- To reply, change domain to an adult feline.
First
|
Prev
|
Pages: 1 2 Prev: enum problem - getting C4482 Next: GetUserNameEx() refuses to work for me. |