Re: TCHAR and buffer overflows
From: Anon E. Maus (anon@maus.duh)Date: 08/26/02
- Next message: Alun Jones: "Re: Privilege-escalation attacks on NT-based Windows are unfixable"
- Previous message: Allan: "Any recommendations for safe network use?"
- In reply to: David Hopwood: "TCHAR and buffer overflows"
- Next in thread: Edward Elliott: "Re: TCHAR and buffer overflows"
- Reply: Edward Elliott: "Re: TCHAR and buffer overflows"
- Reply: David Hopwood: "Re: TCHAR and buffer overflows"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: "Anon E. Maus" <anon@maus.duh> Date: Mon, 26 Aug 2002 01:38:58 GMT
"David Hopwood" <david.hopwood@zetnet.co.uk> wrote in message
news:3D6960C8.AD7DF35F@zetnet.co.uk...
> -----BEGIN PGP SIGNED MESSAGE-----
>
> Edward Elliott wrote:
> > strcpy, strcat, sprintf, and scanf are also common offenders. Even
> > strncpy, strncat, etc don't eliminate buffer overflows; they just make
> > them harder. If you pass a length that's too long, you can get an
overflow.
> >
> > MS had this problem in a lot of their programs. They would write code
like
> >
> > WCHAR buf[256];
> > strncpy(buf, src, sizeof(buf));
This would be a problem if you hadn't defined UNICODE in your build. Hint:
Copy characters of one string to another.
char *strncpy( char *strDest, const char *strSource, size_t count );
wchar_t *wcsncpy( wchar_t *strDest, const wchar_t *strSource, size_t
count );
unsigned char *_mbsncpy( unsigned char *strDest, const unsigned char
*strSource, size_t count );
Routine Required Header Compatibility
strncpy <string.h> ANSI, Win 95, Win NT
wcsncpy <string.h> or <wchar.h> ANSI, Win 95, Win NT
_mbsncpy <mbstring.h> Win 95, Win NT
> >
> > The problem arises when WCHAR is defined as a Unicode character (the
> > macro WCHAR was introduced to switch between ascii and unicode chars as
> > needed).
>
> I think you mean TCHAR (WCHAR always represents a UTF-16 code unit).
> TCHAR is an abomination. For any program that needs to support Unicode,
> decide on a specific UTF for the internal representation and use it
> consistently. This is likely to require additional libraries for
> platforms that have poor OS and/or C library support for Unicode, but
> such libraries are available as open source (e.g. ICU).
>
> > Since Unicode chars are two bytes long, and sizeof returns the
> > size in bytes, sizeof(buf) is actually 512! The fix of course is to use
> > sizeof(buf) / sizeof WCHAR, but the bug is very subtle. Even to most
> > security people, the code looks fine at first.
The code _is_ OK, because the compiler (assuming you are using MS VC++ or
VS) predefines which lib routine to use based on the Unicode settings
(compiler switches). Check your factory headers for TCHAR defs and such,
you'll see what I mean.
>
> It shouldn't look fine to either security people or i18n people.
> strncpy treats the first zero byte in the source string as terminating
> the string, so it simply doesn't work for copying UTF-16 strings. Anyway,
> it will cause a compiler warning due to incompatible types.
//
// Neutral ANSI/UNICODE types and macros
//
#ifdef UNICODE // r_winnt
#ifndef _TCHAR_DEFINED
typedef WCHAR TCHAR, *PTCHAR;
typedef WCHAR TBYTE , *PTBYTE ;
#define _TCHAR_DEFINED
#endif /* !_TCHAR_DEFINED */
>
> Perhaps you meant to say "memcpy(buf, src, sizeof(buf));", but that works
> correctly (assuming sizeof(src) >= sizeof(buf), and that src and buf don't
> overlap) even for TCHAR.
In the MS factory libs, memcpy() memmove(), etc. detect overlapping buffers
and do reverse copy as appropriate.
>
> IME, the skills required to write secure internationalised code are just
> those required to write internationalised code, plus those required to
> write secure code. As long as you're doing both correctly, there are no
> hidden gotchas in the interaction between them.
True; I might add one, though: you have to be familiar with your tools and
how they work. Your work can be only as good as your tools. Lousy tools,
lousy work. Or
good tools, lousy user, lousy work. True quality comes from pride of
workmanship.
Etc.
>
> - --
> David Hopwood <david.hopwood@zetnet.co.uk>
>
> Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
> RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
> Nothing in this message is intended to be legally binding. If I revoke a
> public key but refuse to specify why, it is because the private key has
been
> seized under the Regulation of Investigatory Powers Act; see
www.fipr.org/rip
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: 2.6.3i
> Charset: noconv
>
> iQEVAwUBPWlf/jkCAxeYt5gVAQFEmwgAxs7zKDPqvnqXQzBAmmQ3E4n77RnxtHYV
> MBWuiL0mRbE9xK8hP6cSsu3lUCukhsj3TZ2NefE9UKX3gASNsW0SXMQYU3YRKUwR
> cVWAiwN4srmUddK8kVUsD2/ExrcOwNZdBdrYWc50ZIuK1Jbd0wldPCZPMXyXmUjF
> NgpXaDrqQLiVig2hmess/ChLoYkDIoM/fNbqGKzcQ1gVltfA1VxtkLBg58vvCRWV
> LSnMyFh30Udb4M1zXtL54CHBFQIWQk3OELrNWDCXa4cBw/+6/+EZOj5+rl4NpGwi
> YM6fQDJGXWqYQs9FYJBr9M8iwft9a0D1+/ntD+pRDSHwAAsIcKgtVg==
> =seQo
> -----END PGP SIGNATURE-----
- Next message: Alun Jones: "Re: Privilege-escalation attacks on NT-based Windows are unfixable"
- Previous message: Allan: "Any recommendations for safe network use?"
- In reply to: David Hopwood: "TCHAR and buffer overflows"
- Next in thread: Edward Elliott: "Re: TCHAR and buffer overflows"
- Reply: Edward Elliott: "Re: TCHAR and buffer overflows"
- Reply: David Hopwood: "Re: TCHAR and buffer overflows"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
