Lots of talk about whether a Desktop 64-bit OS is needed or not due to application availability, register addition, and whatnot, yet what about Win-64 and security?
Good question, but I think the wrong approach. You should not look at it as Win-64 vs. WIn-32 because
(for the most part) the bit-level has nothing to do with the Security of the OS. Keep in mind that the
64-bit version of Windows being made for the AMD64 CPUs is based (I'm sure) on the Windows 2003
codebase and the enhancements and patches already applied (or being applied) to Windows XP.
So many of the security issues that seem to pop up now will already have been taken care of.
Will Win-64 be inherently better, worse, or the same, security wise than Win-32?
None of the above (but technically better). What will make Windows XP/2003 for 64-bit better will
be the efforts MS is already making to patch existing flaws in the OS, and their new Security-oriented
design approach, which is meant to reduce/eliminate security holes in the future. Having 64-bit
registers won't make a difference in that regard; what will is integrating all the improvements they've
been able to make in the meantime.
I mean if 32-bit stuff has lots of security problems, then won?t Win-64 and 64-bit apps offer a larger ?bitscape? to plunder, resulting in even more horrendous security nightmares?
No. Because "32-bit stuff" has no more security problems than 8-bit, 16-bit, 64-bit, or 128-bit stuff.
The problem is not at the bit level. It is in how the code (variables, buffers and pointers) were
designed in the first place. If they were designed without proper boundaries checks, or garbage
collection routines, then the same security issues would arise regarless of OS (and even Linux has
been subject to this problem).
Having a larger "bitscape" would actually make it harder to plunder, because a hacker would have to
spend a lot more time (days in some instances) trying to exploit a larger variable, whereas the OS
is/has been redisigned to recognize such attempts and either delete them or ignore them.
Is Win-64 being written new or is it just an extension of existing Win-32 code, thus inheriting its horrible buffer control and other security issues?
Neither (see above).
1st, it makes no sense to reinvent the wheel. Windows XP/2003 are make up of millions of lines of
code, most of which does not have security issues. It would literally take decades to rewrite the
whole OS from scratch, and would be completely unnecessary. That is what
code review is
for... When you have an outside agency (or a different design team) look over the code that is already
written to identify flaws or security holes, have them try to think up ways and suggestions of how the
existing code could be improved (without breaking everything else that depends on it), or you hire
a bunch of hackers to try and break into the code you've already written, to make sure that common
exploits like buffer overrun errors cannot give an outside user command access to the machine.
Some parts of the OS will be re-written, but mostly with the idea of improving on the algorithm that
was used before. Not so much to try and do it in a different way - unless that different way takes
advantage of new features in the hardware that were not available before.
These are all things that MS claims to be doing to improve their code base.
How much of the buffer overflow problem is due to the OS's buffer handling vs. due to a particular application's?
Both. The problem with buffer overflow is not that it exists (there are a lot of places where buffer overflows can happen); its that some of the buffer overflows fail in such a way that allows a cracker to pass commands
on to the root level of the OS to be executed. Most often that happens as an exploit to an OS level
service like IIS or SQL Server, or in the browser. But the problem is that is that, instead of having the
command fail and be discarded, it is passed on to the OS; and the OS executes it because it "trusts"
the program that passed it the command in the first place.
Will a 32-bit app running in a 64-bit OS have its same security attributes as on a 32-bit OS ? in other words, will a 64-bit OS be neutral to, squelch, or enhance 32-bit app buffer overflow problems?
See above. If the 64-bit OS was just a port of the original release of XP, then it would be neutral
to expoits on 32-bit apps. But we are assuming that Windows XP/2003 for AMD64 (and Itanium 2)
will have all the patches and fixes already applied from the start.
Will Win-64 apps be written with better security than Win-32 apps?
Yes and No. It will be up to the individual developers to improve on the security in thier designs when
writing/re-writing programs for 64-bit; so 64-bit will not be inherently any more secure that 32-bit.
But... There is a lot more emphasis on "secure by design" at MS these days, and their tools should
also reflect that attitude. So, going forward, it will be easier for developers to think about security
in their programs because the tools and platform will encourage it.
Security issues for Win-64 will be important factors for migrating from Win-32, so what?s known?
What is known (or what can be implied).
1. Microsoft is a lot more serious about security than they used to be.
This I can confirm from having seen talks given by actual MS program managers, by observations
made at the launch of Windows 2003 / Visual Studio.NET, and by seeing more effort being put into
providing patches for the OS and applications before exploits become widespread.
2. Going to 64-bit give MS a better postion to compete in the Enterprise Server market.
Issues about security and stability of the OS platform are even more important in that market segment
than on the desktop; and it would become a major selling point for Microsoft to be able to say (and prove)
that they are as secure to deploy in that market as their competition.
3. Going to 64-bit allows MS to leave a lot of baggage behind.
Along with the opportunity to provide newer/cleaner code, the move to the new 64-bit platforms
along allows MS to drop support for legacy hardware that will not be included in new systems. That
can allow them to tighten up on driver development and support, which is another area that
is infamous for causing stability problems for the OS.
... Just my opinion.
