OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
Bugtraq archives for 3rd quarter (Jul-Sep) 1998: Re: ncurses 4.1 security bug

Re: ncurses 4.1 security bug

David Schwartz (davidsWEBMASTER.COM)
Thu, 9 Jul 1998 20:35:11 -0400 

> In C++ _you cant_
>
> C++ global object constructors are called in pretty much arbitary
> order before
> main() is entererd.
>
> Its an interesting reason not to write setuid apps in C++ 8)

        Constructing global objects is bad anyway for a variety of reasons and
tends to cause subtle bugs since the order is indeterminate. For example, if
a class initializes global objects for its own tracking and you create an
instance of the class globally, you have no way to know whether the class is
internally ready to function or not. In general, you have no way to know if
a class relies upon global initialization.

        Imagine if you do, globally, 'MyString foo("test");' but unknown to you,
'MyString.h' has:

class MyString
{
 private:
 static int StringCount;
 ...
 public:
 MyString(const char *f)
 {
  StringCount++;
  ...
 }
};

        and 'MyString.cpp' has:

int MyString::StringCount=0;

        Constructing an instance of such a class globally is suicide.

        It's far better to use global _pointers_ and initialize them with calls to
'new' from your 'main' function. Constructing 'complex' global objects is a
losing proposition to begin with. And, in general, almost every global
variable can be eliminated by clean coding.

        DS