So many publications attempt to summarize the year in technology news that I think It would be better for me to focus instead on what we can gather from what happened once the dust has settled.
2010 was an interesting year on many accounts, especially on how wrong the pundits and "consultants" were.
This was supposed to be the year that the Android OS overtakes iOS (the iPhone OS) as the preferred mobile platform. Hasn't happened. In fact, I would venture to say, that despite the stellar debut of the iPad tablet, the iPhone was the star of the year.
From the debut of the iPhone 4, to the ever expanding AppStore repertoire, to rumours of a Verizon iPhone. The iPhone has been on everyone's lips and remains fixed in the publics consciousness.
I will not dispute that there might be more Android phones out there than there are iPhones. The latter's edge however is that its owners usually replace their iPhones with another and that newcomers to the smartphone market ask for it by name. The Android phones seem to be the generic alternative that people get when the can't think of what to ask for. I recall hearing a PC Magazine commentator saying that the Android platform's biggest weakness is its inconsistency and lack of uniformity.
Having written what could be interpreted as paean to the iPhone, I will refrain from committing the same mistake I rail against so-called experts for. I will not predict which platform will come out on top in 2011, but I will say that the Android is not the shoo-in that many claim it will be.
I will venture to predict though that the iPad may experience a resurgence in the next 12 months. Apple deserves credit not only for giving tablets new life but for insuating it into more areas of life thant any other company that has marketed them before.
"Honored more in the breach than in the observance," the PC must be mentioned for its near absence from techology news. I say this to point out how subtly specialized devices called computeres are being replaced by devices with similar computing power but different designations. I think 2011 will mark the continuation of that trend.
Friday, December 31, 2010
Monday, June 14, 2010
Google, Windows and Security
The Financial Times reported toward the end of last month that Google was going to stop issuing computers running a Microsoft Windows operating system to their employees, with very few exceptions.
The story has caused some furor in IT circles with many opinion columnists warning about the "consequences" of such a sweeping decision. It's hard to understand how anyone could be surprised by this move given Google's Chinese operation being
hacked due to vulnerabilities in their Windows computers.
In fact, I was surprised the search giant was still using Internet Explorer internally given the very warnings published on Googles own site. Yet, the attack did exploit vulnerabilities even Google had not documented.
It is interesting though how so many are now taking on the role of advisors to Google on their OS decision. PC World columnist Tony Bradley, for example, criticized the move while using the oft-cited platitude that Windows has more viruses because it has more users.
Mathematical modeling might suggest that the most used OS will be the one most targeted by by hackers, and the concept cannot be proven to be totally false. However, this alone is not a valid argument nor does it comport with other realities of computing.
Although most users access the Internet using a Microsoft OS, the majority of servers run a Unix-based OS. Given the greater documentation and source code available for the various *NIX operating systems, these servers should be an easier target for exploits. After all, it is much easier to get the fixed IP address of an unpatched server than the transient IP of a broadband subscriber. Yet, it is the latter that gets hit most often, but only if he or she is running a certain browser/OS combination.
Some of the arguments I have been reading from Widows advocates quote the famous yearly Pwn to Own contest as proof that OS X is insecure. However, some of these same people eschew the very same result set and quote Secunia advisories instead to prove that Linux is insecure.
Two things become clear from such truncated arguments:
1) neither result set can be used by itself as a determinant of OS security, especially given real world evidence, and
2) the tap-dancing betrays a lack of seriousness and intellectual honesty.
Moreover, from the comments by Windows users that I have read in which they explain how much better Microsoft security is, I gather they do not understand how UNIX security works.
Let's begin by admitting freely that all operating systems have vulnerabilities.
Even when there isn't an OS-borne vulnerability, plugins and applications such as Adobe Flash, Acrobat Reader or Microsoft Windows Help And Support Center may introduce one — as of today, these three are at the top of Secunia's list interestingly enough, but lets move on.
While Windows OSes are built on the NT base which is based on the old VMS model. All Linux distros and Mac OS X, are based on a UNIX architecture to one degree or another.
There are fundamental differences in how these two OS families are structured. Without judging just yet, let's examine the key differences between security models.
In the UNIX world security is based on ownership. Ownership determines access and access determines privilege. All files are owned and all objects are treated as files. There is a superuser who initially owns everything and can dole out privileges and ownership to other users.
In Windows machines the security model is access based. There are user access controls (UACs) and access control lists (ACLs). A file's owner is more of an attribute that is mapped to the an ACL. Unlike UNIX there is a "system" that owns processes and files. This "system" is not a login user (and is not subject to any UAC or ACL) but plays the role of owner of last resort, not necessarily subject to the "Admin" or most privileged login user. Such splitting of the superuser's powers is baffling to UNIXheads.
The merits of each system versus those of the other could be debated ad nauseam. In fact, I think many pubs owe their livelihood to throngs of UNIX and windows sysadmins imbibing enormous amounts of libation while deliberating on these differences.
In the real world, however, the UNIX system has consistently proven to be a lot more resistant to outside attacks. Day after day millions of windows machines get exploited and controlled the world over, while their nearby Linux and Mac counterparts (even on the same networks) are untouched.
I think the main reason for this is that, in Windows, the elusive "system" user can be easily manipulated or impersonated by a hacker. I remember a particular vulnerability I witnessed where a rogue website operator could open a command window and perform system tasks without the local user even seeing what was going on.
The worse part is that, since "System" has a higher rank than "Admin" in the Windows hierarchy, even an alert administrator can only counteract such attacks by pulling the power plug or the network cable. Is it any wonder how so many trojan horses, worms and malware can get installed so fast on so many systems?
To achieve comparable access on a UNIX-type system, a hacker would have had to steal a root or superuser password. Or the superuser would have had to have opened up too many doors to guest users. The only ways for the former to happen is for the hacker to pry the information from sysad or physically break into the data center.
Another weakness in Windows systems is the Registry, which no version of windows seems to ever check for integrity or validity before loading the values it contains. However, the Registry controls just about every aspect of the system's operations.
Many of the infections I have had to clean from Windows computers have taken advantage of various Registry hacks. The irony of this [and I faced this not long ago when dealing with a particular virus] is that, although a user can be prevented from accessing RegEdit, the Registry editing tool, the hacker's script can freely modify it because the malware runs with System privileges!
Another Windows weakness is Internet Explorer. Although Microsoft has been improving on it's flagship browser over the years, the nexus between Windows Explorer (its Window Manager) and IE provides a handy backdoor for mischief. To make matters worse, the same scripting engine used for local shell tasks is used by the browser to control web pages. ActiveX (a binary execution layer and plug-in container) and VBScript are probably the two biggest holes in IE, and JScript is not far behind.
Despite all these issues, most IT departments do not have the options that Google's has. For reasons of culture, convenience or necessity, they must support machines running one or more versions of Windows operating systems. Also, despite the proven security of competing operating systems, "social engineering" — hackers fooling users into cooperating with them— remains a big vulnerability in any shop.
The bottom line is that, having honestly assessed what the risks are — without spin, sophistry or FUD— IT departments need to proceed with caution and remain vigilant to keep their systems uncompromised. As an old US Army slogan went, "OPSEC is 24/7."
The story has caused some furor in IT circles with many opinion columnists warning about the "consequences" of such a sweeping decision. It's hard to understand how anyone could be surprised by this move given Google's Chinese operation being
hacked due to vulnerabilities in their Windows computers.
In fact, I was surprised the search giant was still using Internet Explorer internally given the very warnings published on Googles own site. Yet, the attack did exploit vulnerabilities even Google had not documented.
It is interesting though how so many are now taking on the role of advisors to Google on their OS decision. PC World columnist Tony Bradley, for example, criticized the move while using the oft-cited platitude that Windows has more viruses because it has more users.
Mathematical modeling might suggest that the most used OS will be the one most targeted by by hackers, and the concept cannot be proven to be totally false. However, this alone is not a valid argument nor does it comport with other realities of computing.
Although most users access the Internet using a Microsoft OS, the majority of servers run a Unix-based OS. Given the greater documentation and source code available for the various *NIX operating systems, these servers should be an easier target for exploits. After all, it is much easier to get the fixed IP address of an unpatched server than the transient IP of a broadband subscriber. Yet, it is the latter that gets hit most often, but only if he or she is running a certain browser/OS combination.
Some of the arguments I have been reading from Widows advocates quote the famous yearly Pwn to Own contest as proof that OS X is insecure. However, some of these same people eschew the very same result set and quote Secunia advisories instead to prove that Linux is insecure.
Two things become clear from such truncated arguments:
1) neither result set can be used by itself as a determinant of OS security, especially given real world evidence, and
2) the tap-dancing betrays a lack of seriousness and intellectual honesty.
Moreover, from the comments by Windows users that I have read in which they explain how much better Microsoft security is, I gather they do not understand how UNIX security works.
Let's begin by admitting freely that all operating systems have vulnerabilities.
Even when there isn't an OS-borne vulnerability, plugins and applications such as Adobe Flash, Acrobat Reader or Microsoft Windows Help And Support Center may introduce one — as of today, these three are at the top of Secunia's list interestingly enough, but lets move on.
While Windows OSes are built on the NT base which is based on the old VMS model. All Linux distros and Mac OS X, are based on a UNIX architecture to one degree or another.
There are fundamental differences in how these two OS families are structured. Without judging just yet, let's examine the key differences between security models.
In the UNIX world security is based on ownership. Ownership determines access and access determines privilege. All files are owned and all objects are treated as files. There is a superuser who initially owns everything and can dole out privileges and ownership to other users.
In Windows machines the security model is access based. There are user access controls (UACs) and access control lists (ACLs). A file's owner is more of an attribute that is mapped to the an ACL. Unlike UNIX there is a "system" that owns processes and files. This "system" is not a login user (and is not subject to any UAC or ACL) but plays the role of owner of last resort, not necessarily subject to the "Admin" or most privileged login user. Such splitting of the superuser's powers is baffling to UNIXheads.
The merits of each system versus those of the other could be debated ad nauseam. In fact, I think many pubs owe their livelihood to throngs of UNIX and windows sysadmins imbibing enormous amounts of libation while deliberating on these differences.
In the real world, however, the UNIX system has consistently proven to be a lot more resistant to outside attacks. Day after day millions of windows machines get exploited and controlled the world over, while their nearby Linux and Mac counterparts (even on the same networks) are untouched.
I think the main reason for this is that, in Windows, the elusive "system" user can be easily manipulated or impersonated by a hacker. I remember a particular vulnerability I witnessed where a rogue website operator could open a command window and perform system tasks without the local user even seeing what was going on.
The worse part is that, since "System" has a higher rank than "Admin" in the Windows hierarchy, even an alert administrator can only counteract such attacks by pulling the power plug or the network cable. Is it any wonder how so many trojan horses, worms and malware can get installed so fast on so many systems?
To achieve comparable access on a UNIX-type system, a hacker would have had to steal a root or superuser password. Or the superuser would have had to have opened up too many doors to guest users. The only ways for the former to happen is for the hacker to pry the information from sysad or physically break into the data center.
Another weakness in Windows systems is the Registry, which no version of windows seems to ever check for integrity or validity before loading the values it contains. However, the Registry controls just about every aspect of the system's operations.
Many of the infections I have had to clean from Windows computers have taken advantage of various Registry hacks. The irony of this [and I faced this not long ago when dealing with a particular virus] is that, although a user can be prevented from accessing RegEdit, the Registry editing tool, the hacker's script can freely modify it because the malware runs with System privileges!
Another Windows weakness is Internet Explorer. Although Microsoft has been improving on it's flagship browser over the years, the nexus between Windows Explorer (its Window Manager) and IE provides a handy backdoor for mischief. To make matters worse, the same scripting engine used for local shell tasks is used by the browser to control web pages. ActiveX (a binary execution layer and plug-in container) and VBScript are probably the two biggest holes in IE, and JScript is not far behind.
Despite all these issues, most IT departments do not have the options that Google's has. For reasons of culture, convenience or necessity, they must support machines running one or more versions of Windows operating systems. Also, despite the proven security of competing operating systems, "social engineering" — hackers fooling users into cooperating with them— remains a big vulnerability in any shop.
The bottom line is that, having honestly assessed what the risks are — without spin, sophistry or FUD— IT departments need to proceed with caution and remain vigilant to keep their systems uncompromised. As an old US Army slogan went, "OPSEC is 24/7."
Thursday, March 25, 2010
What Apple Should Not Learn From Microsoft
Mac enthusiasts have chided Apple, Inc, for not having the marketing savvy of rival Microsoft. The implication is that the Cupertino tech powerhouse should learn from the Redmond giant when it comes to the ways in which the latter grows its market share.
I cannot argue with that; in fact I think there is probably a lot of truth to it. However, it is now clear to me that there is one thing Apple has learned to do the Microsoft way a little too well: making the default browser run with too many privileges.
According to a PC World report, researchers participating in 3Com's annual Pwn2Own competition were able to hack into both the latest iPhone and Macintosh computers using the Safari web browser as attack vector.
Although it is not initially apparent to the average user how much privilege the Mac version of Safari runs with, the iPhone version is too ubiquitous and is used in too many cases on the portable device to not be seen as a base app with tentacles in many of its functions.
It seems as if the Mac's Dashboard desktop application uses the same WebKit rendering engine that Safari uses; and therein lies the weakness the browser represents. Just as with Microsoft, Apple could not resist the temptation to sacrifice security on the altar of efficiency.
What should Apple do? I was initially tempted to suggest that they take a page from Konqueror, the browser used by the KDE project. It integrates with the UI yet appears to be quite secure. I remember being warned by it when it detected a rogue website containing a VBScript exploit that would have allowed a hacker to gain command line control of a client Windows machine.
However, I am a little cautious because Konqueror would not have been vulnerable to such an attack even if it had not been detected. I am left to wonder if it would be as resilient with an attack tailored toward a language it has a runtime for.
Either way, I must at least credit the Konqueror web browser if only because its creators seemed to have been aware of the possibility of such attacks, unlike their fellow WebKIt users over at Apple.
At the end of the day, however, it all seems to boil down to privileges. If both the web browser and the UI shell — with its almost unlimited access rights — are to use the same rendering engine for HTML/XML content, then a way needs to be devised that will grant or deny privileges based on the source of invocation.
The Snow Leopard exploit granted command line access to a hacker for the computer running Safari. The iPhone OS vulnerability, for its part, allowed access to the devices SMS contact list. Although the details of the attacks have not been fully disclosed, we can safely infer that both exploits gave unauthorized local access to a remote user by using the web rendering engine or its parent process.
Maybe the rendering engine should be rewritten in a way that checks for the credentials of the invoker. Maybe, the OS should run a separate copy for local tasks. Whatever the solution, this pivotal security barrier should never be broken.
When a third party browser, such as Firefox or Opera, is run. Obviously, the incestuous relationship between browser and OS shell is to blame. Come on, Apple, you know better than to learn from the OS family with possibly the worst security record in the history of computer operating systems.
I cannot argue with that; in fact I think there is probably a lot of truth to it. However, it is now clear to me that there is one thing Apple has learned to do the Microsoft way a little too well: making the default browser run with too many privileges.
According to a PC World report, researchers participating in 3Com's annual Pwn2Own competition were able to hack into both the latest iPhone and Macintosh computers using the Safari web browser as attack vector.
Although it is not initially apparent to the average user how much privilege the Mac version of Safari runs with, the iPhone version is too ubiquitous and is used in too many cases on the portable device to not be seen as a base app with tentacles in many of its functions.
It seems as if the Mac's Dashboard desktop application uses the same WebKit rendering engine that Safari uses; and therein lies the weakness the browser represents. Just as with Microsoft, Apple could not resist the temptation to sacrifice security on the altar of efficiency.
What should Apple do? I was initially tempted to suggest that they take a page from Konqueror, the browser used by the KDE project. It integrates with the UI yet appears to be quite secure. I remember being warned by it when it detected a rogue website containing a VBScript exploit that would have allowed a hacker to gain command line control of a client Windows machine.
However, I am a little cautious because Konqueror would not have been vulnerable to such an attack even if it had not been detected. I am left to wonder if it would be as resilient with an attack tailored toward a language it has a runtime for.
Either way, I must at least credit the Konqueror web browser if only because its creators seemed to have been aware of the possibility of such attacks, unlike their fellow WebKIt users over at Apple.
At the end of the day, however, it all seems to boil down to privileges. If both the web browser and the UI shell — with its almost unlimited access rights — are to use the same rendering engine for HTML/XML content, then a way needs to be devised that will grant or deny privileges based on the source of invocation.
The Snow Leopard exploit granted command line access to a hacker for the computer running Safari. The iPhone OS vulnerability, for its part, allowed access to the devices SMS contact list. Although the details of the attacks have not been fully disclosed, we can safely infer that both exploits gave unauthorized local access to a remote user by using the web rendering engine or its parent process.
Maybe the rendering engine should be rewritten in a way that checks for the credentials of the invoker. Maybe, the OS should run a separate copy for local tasks. Whatever the solution, this pivotal security barrier should never be broken.
When a third party browser, such as Firefox or Opera, is run. Obviously, the incestuous relationship between browser and OS shell is to blame. Come on, Apple, you know better than to learn from the OS family with possibly the worst security record in the history of computer operating systems.
Subscribe to:
Posts (Atom)