begin oe_protect.scr
Roy Schestowitz <newsgroups@xxxxxxxxxxxxxxx> espoused:
> __/ [ Roy Schestowitz ] on Wednesday 02 August 2006 18:31 \__
>
>> __/ [ Richard Rasker ] on Wednesday 02 August 2006 18:29 \__
>>
>>> Op Wed, 02 Aug 2006 06:23:19 -0700, schreef nessuno@xxxxxxxxxxxxxxxxxxx:
>>>
>>>> I wish I understood this better. Regarding buffer overflows, I don't
>>>> understand why you don't just fix the bugs. Even with Windows and
>>>> 50,000,000 lines of code with the resources they have MS ought to be
>>>> able to find all the gets() statements and just fix them. Instead some
>>>> time ago I heard that MS was looking to hardware solutions, putting
>>>> buffers in one area of memory with some kind of protection, and code
>>>> into another. It sounded really kludgey to me. Now this article is
>>>> again talking about hardware solutions. Encrypting instructions and
>>>> doubling the execution time sounds really horrible. Scientific
>>>> programmers would have a fit. BTW, although the experiments in this
>>>> article were carried out on Linux, I don't see why the same techniques
>>>> wouldn't work for any OS. As I say, they don't involve fixing *bugs*.
>>>> But obviously I'm not understanding something.
>>>
>>> Fixing things once and for all isn't in the interest of Microsoft and the
>>> rest of the industry. Their business would quickly collapse if they'd
>>> start churning out (near) flawless products. It's much more profitable to
>>> make people pay a mint for quickly slapped-together, sloppy software, and
>>> make them pay again for all kinds of half-baked measures meant to lessen
>>> the negative effects of the poor primary product. And if these measures
>>> consume huge amounts of system resources: all the better. People will go
>>> out and buy new computers with new Windows licenses even sooner.
>>
>> A moral company would turn to the customer and say "Look, Vista will not be
>> secure in the long run, but we can try to help. The competition is indeed
>> offering more security, but we promise to catch up". In reality, however,
>> Microsoft (Ballmer) is conceited and any fears will worry the investors and
>> be adverse to the strategy. So they carry on hiding the truth...
>>
>> Microsoft knows it's behind in many areas. It is scared and it is trying to
>> empty its pockets' reserves to hide the truth from people. I don't think
>> it's sustainable though. People will wake up and talk. The impact of word
>> of mouth is exponential.
>
> Addendum: there was a relevent article in The Inqeuirer some months ago. It
> describes how Ballmer spoke to the crown as though they were locked up in
> Oz. He had raved about security in Vista just before all the turths leaked
> out, courtesy of consultants (one of them was Gartner) and AV vendors
> (notably Symantec, which sacked 25 employees today). What bothers me is
> this: how can a person who is a manager, as opposed to an engineer, actually
> tout security? And why am I not surprised that it was all nothing by sales
> pitch and void promises? Vista will not be secure. That's a fact. SPAM will
> continue to increase, as well as the many problems that we see as a result,
> e.g. hospital computer systems becoming a zombie army, people's data locked
> and asked to pay random... and confidential data leaks out of University
> servers. To name a few examples I can think of quickly...
>
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.
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.
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.
Therefore, although MS perhaps could fix a lot of these problems, it's
quite likely that it's impractical for them to do so, as it would not
only take up vast resources, but also, it would likely break any number of
3rd-party and other MS apps, with no way of testing/fixing the problems.
There would be a consumer outcry, I think, with MS being accused of
deliberately breaking 3rd-party apps, particularly if they'd been able
to fix their own apps.
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...
--
| Mark Kent -- mark at ellandroad dot demon dot co dot uk |
BREAKFAST.COM Halted... Cereal Port Not Responding.
|
|
