begin oe_protect.scr
nessuno@xxxxxxxxxxxxxxxxxxx <nessuno@xxxxxxxxxxxxxxxxxxx> espoused:
>> Fixing buffer overflows is not completely trivial, as there are so many
>> ways of getting them... I think modern compilers tend now to warn if
>> you use functions which don't do bounds checking, like gets, (x)scanf,
>> strcpy, strcat, sprintf & vsprintf. The best approach is to avoid such
>> functions in the first place, I think, but with something like the Windows
>> code-base, whilst identifying all instances of the above in 50E06 lines
>> of code, and then /fixing/ those problems would take some time.
>
> Well, they've had some time.
>
>>
>> Then there'd be the nightmare of dependencies within the Windows
>> environment; somehow, the fixes would have to be tested and implemented
>> such that existing applications still ran, as Microsoft would have no way
>> of recompiling 3rd-party apps against new library functions themselves,
>> and might even have problems with their own applications.
>
> Of course if it were just buffer overflows, you could make sure
> everything worked with valid input, just change so it fails gracefully
> with invalid input. (I know I'm being naive.)
>
>>
>> Unlike Linux distributions, which have built up a culture of recompiling
>> from source when changes are made, and issuing new binaries, Microsoft
>> have absolutely avoided such an approach. There is no structure in
>> place to ensure that applications are recompiled against new versions of
>> libraries, and no testing infrastructure to make sure that applications
>> will all play together effectively once new versions have been released.
>
> Is this true?? Gawd, it's awful! How can any decent programmer stand
> to work in such an environment? It just reinforces my earlier
> sentiment, however, that the hardware fix to the software problems is
> kludgey.
>
>> Having said all of that, buffer overflows are only one of many major
>> security flaws in Windows, others include the use of file extensions to
>> determine executability, the poor shell design(s) which can permit
>> execution from mail, websites and so on, activeX, deeply embedded html
>> rendering engines, obfuscation of "open" and "run", most users running
>> as "admin" to keep legacy apps going or to easily handle situations MS
>> haven't thought through properly, mounting of filesystems (particularly
>> a lack of "noexec" for such as USB mounts), easily compromised password
>> hashes, overly tight integration of apps and OS. And so on...
>
> Apparently Vista is trying to fix these problems with more kludges laid
> on top of earlier kludges...if so, it won't work very well, even if
> they do succeed in lowering the security threat in the most common
> situations. Makes me think that Dvorak is right, they should throw out
> the XT code and go back to 2000 and start from there...except maybe
> 2000 isn't early enough.
>
> You know, I used to think that you Linux guys were exaggerating
> somewhat when you talked about all the poor design in Windows. I don't
> personally know. But when I read the Wall Street Journal article,
>
> http://www.wsjclassroomedition.com/archive/06jan/bigb_microsoft.htm
>
> I said, Good grief! Those guys are right (about the spaghetti code in
> Windows).
>
Have you looked at the dates quoted in that article? Someone is playing
fast & loose with the timelines. The "reset" to Windows was reported
this year, the "reset" was claimed to be last year, but later it's also
claimed to have been in 2004, too. So which is it?
This reads like an attempt to claim that things have been fixed at
Microsoft, whereas I'm not so sure that they have.
--
| Mark Kent -- mark at ellandroad dot demon dot co dot uk |
BREAKFAST.COM Halted... Cereal Port Not Responding.
|
|
