The article says that the passengers are provided with Internet access while onboard.
And the joke was that if they used Ethernet, and were stupid enough to use the same Ethernet switches for the entertainment and the flight control networks, the entire system would be vulnerable to the Ethernet Loop denial-of-service attack:)
1. Get on a plane 2. Find two unused Ethernet ports 3. Connect them with a cable, forming a loop 4. The flight control box, running Vista, cannot cope with the traffic due to 10000 packets/second limit </sarcasm>
On older motherboards it often helps to change the Power Options from the 'Balanced' setting to 'Always On'.
This way Vista will never throttle down the CPU, or use chipset-specific low-power states (STOPGRANT, etc.) while the system is running.
You can still set up your own monitor/hard disk/sleep timeouts if you like.
Most of the claims of that patent involve a networked version of a card game, where users play simultaneously with a "computer opponent". Things such as advertising and scoreboards are mentioned as well.
So, the Windows Solitaire is less susceptible than a Web-based card game with advertising/leaderboard.
You know, some older motherboards have these 'singing' coils - if you write a simple loop that changes the power draw of the CPU roughly 500-2000 times per second, you can make audible sound. I bet you can play Jingle Bells this way without having to take anything apart:)
> and the write speeds aren't so good This is so not true.
The read/write speed of a mechanical hard drive has well-defined physical limits (at most, it is rotational speed * bytes per track * number of heads). And even then, modern hard drives do not use more than 1 head at a time because it makes the drive significantly more complicated with little benefits compared to a RAID array. The read/write speed of a large solid state disk is mostly limited by the controller design, not by the Flash chips.
Let's say we build a 256GB hard drive using 32GBit Flash chips, 20MByte/sec speed (which is quite slow by todays standard). Using just 64 of such chips, we can design a device which does 1280MB/sec.
The problem is that most consumer-level hardware is only tested with the most common TCP settings, so, changing the TCP receive window (RWIN) or maximum transfer unit (MTU) often reveals hidden bugs in their TCP/IP implementations.
Even the subtle changes in timing of the packets may trigger previously undiscovered bugs.
In my case, the web interface of the Acorp LAN420 ADSL router was 'freezing' 75% of the times when accessed from Vista(RTM). Upgrading to the latest firmware solved this problem.
If everything else fails, you can try disabling RWIN scaling by running this as administator:
netsh interface tcp set global rss=disabled
netsh interface tcp set global autotuninglevel=disabled
(to see the list of available options, just run 'netsh interface tcp set global')
Although there is no official word from Microsoft about Jet deprecation, Microsoft has stopped actively developing Jet.
There are numerous clues which may indicate Jet deprecation:
1. Jet is not ported to x64 platform, and probably will never be, according to MS devs.
You can only install 32-bit Jet 4.0 SP8 on an x64-based Windows OS.
Since Jet is an in-process component, it is not possible to use a Jet database in a 64-bit application.
2. Access 2007 uses its own, non-redistributable database back-end, codenamed Ace. Jet databases are supported only for legacy reasons.
3. Jet libraries have been removed from MDAC 2.8 package. You have to install Jet 4.0 separately.
4. Many newer MS articles and whitepapers suggest using SQL Server 2005 Express as opposing to Jet, as a superior technology.
Couldn't reproduce this with.txt - Notepad opens in my case (i'm using Word 2003).
Also, if you select something in Word and drag-and-drop it to a folder, a 'Scrap' file will be created with a hidden extension (.shs).
This is one of the examples of ActiveDocument container dangers -.shs file may contain any ActiveDocument content.
Another way to exploit the ActiveDocument vector is to use Insert->Object...->Word Document command in PowerPoint, Excel, and even Wordpad:)
So, even explicitly opening RTF's in WordPad is not perfectly safe.
While you definitely should not rely on extension filtering, if a Word document has a completely random extension, it will not open with Word by default. However, since Word classic.doc format is based on ActiveDocument and OLE Compound Storage format, you can embed Word content into quite a lot of files.
So, opening any OLE Compound Document by an application supporting Active Document (including Word itself) could be dangerous.
However, double-clicking on document.qwer is actually harmless, unless you choose Microsoft Word when prompted to select an application.
When you buy your new 1GB video card (and they already exist), and wonder why only less than 3GB of 4GB of your physical memory is usable, you will really need an x64 OS.
(The fourth gigabyte can still be accessed with PAE if motherboard supports >32bit physical addresses, but PAE itself is an ugly kludge.)
I had a similar problem when I was trying out SuSE Linux 9.1 x64 a couple of years ago.
The installation went OK, however, the keyboard never worked in GRUB, even if 'USB Legacy Support' was enabled.
After some fiddling, I finally had to give up and use a PS/2 converter.
I think the problem is somehow related to the fact that the keyboard was not just a USB HID keyboard device, but a USB Composite device, containing two USB HID descriptors (a keyboard + a mouse).
The mouse descriptor is probably there because the keyboard has a scroll wheel, which works exactly like a mouse scroll wheel without installing any additional software.
NTFS design allows for 2^64 clusters.
Thus, with a 4096 byte cluster size, it can handle 2^26 Petabyte volumes.
The problem is that the current NTFS driver uses 32-bit integers to manipulate the cluster IDs - hence the 256 TB limit, using the largest supported cluster size (64KB).
I don't know about the x64 versions - probably the limit is still there because Microsoft doesn't care much about it at the moment.
It is possible to use MSHTML and not depend on any of IE's security settings - you just have to implement some additional interfaces in the application that uses MSHTML.
These are IInternetSecurityManager/IInternetZoneManager and also IInternetSecurityManagerEx/IInternetZoneManagerEx in Windows XP SP2.
I used MSHTML quite extensively, including running server-generated scripts from the HTML code and using the objects implemented by the host from those scripts. When done properly, IE security settings just don't affect any functionality.
Of course, relying on the default security manager to allow such behavior (like Symantec did) is stupid.
Actually, simple DVD-Rs and modified DVD player firmware could be used for that.
Just make sure that the DVD player destroys the first few tracks (the TOC) before ejecting the DVD:-).
And make the data format of the TOC slightly different so that the unmodified/unhacked firmware won't read these DVD-Rs.
One killer flaw, though - not every DVD player is also a DVD recorder.
It is not a brand new IE feature, it is just a set of locked-down default security settings probably too harsh for average home user (a.k.a. 'Enhanced Security Configuration' - you can revert to WinXP default settings in 10 seconds if you want).
This is reasonable on servers, but too restrictive to put that in Vista.
The ability to control (and disable by default) the loadable COM components without the Registry Editor (browsing through 1000's of COM GUIDs) is new in IE7, and that is a welcome improvement:).
Note: this functionality is NOT covered by the "Manage Add-ons" panel in XP SP2.
Good point about IObjectSafety in SP2.
MS has raised the "bar" a bit further up by this, leaving old buggy code behind the bar.
However, if malware ever gets installed and gains admin access, it is quite pointless to defend against it.
Even the new IE7 opt-in system is going to be fooled - but *until* your system is rooted, you are in control of the COM components that can be used against you - and that's the point.
This, in fact, should reduce the IE's attack surface several-fold.
MS has made a huge mistake when IE 4.x-6.x relied on CATID_SafeForScripting/CATID_SafeForInitializing COM component categories to make decisions whether it's safe to use the COM component from a JavaScript/VBScript.
CATID_SafeForScripting is not needed when the COM component is accessed from a stand-alone.VBS/.JS script stored on the local machine (which is trusted to do anything anyway), yet a lot of MS and third-party components is in CATID_SafeForScripting for no reason at all.
IE has a kill bit feature which allows disabling certain scriptable COM components based on their GUIDs.
And most IE security fixes are, in fact, just registry updates adding more of those "kill bits".
There have been speculations about all these 1207 pins in AMD's SocketM2 (due somewhere in 2006) will be used for an integrated PCIe controller.
http://www.theinquirer.net/?article=24756
The whole point of requiring the HDCP support in displays is to move from software obfuscation to hardware-imposed restrictions.
Neither the OS nor the applications running on it will be able to directly access an HDCP-protected stream, unless explicitly allowed to (in theory;)).
HDCP is just an evil feature of HD-DVD/Blu-Ray, and Microsoft just adds the OS-level support for this stuff.
So, in fact, there could be an opportunity for an open and legal implementation of HDCP on Linux.
Not only that, but the size of a dish required to focus the sunlight on the "barrel" is not mentioned.
The article says that the passengers are provided with Internet access while onboard. :)
And the joke was that if they used Ethernet, and were stupid enough to use the same Ethernet switches for the entertainment and the flight control networks, the entire system would be vulnerable to the Ethernet Loop denial-of-service attack
You don't even need a security hole, see:
1. Get on a plane
2. Find two unused Ethernet ports
3. Connect them with a cable, forming a loop
4. The flight control box, running Vista, cannot cope with the traffic due to 10000 packets/second limit
</sarcasm>
On older motherboards it often helps to change the Power Options from the 'Balanced' setting to 'Always On'.
This way Vista will never throttle down the CPU, or use chipset-specific low-power states (STOPGRANT, etc.) while the system is running.
You can still set up your own monitor/hard disk/sleep timeouts if you like.
Most of the claims of that patent involve a networked version of a card game, where users play simultaneously with a "computer opponent".
Things such as advertising and scoreboards are mentioned as well.
So, the Windows Solitaire is less susceptible than a Web-based card game with advertising/leaderboard.
You know, some older motherboards have these 'singing' coils - if you write a simple loop that changes the power draw of the CPU roughly 500-2000 times per second, you can make audible sound. :)
I bet you can play Jingle Bells this way without having to take anything apart
> and the write speeds aren't so good
This is so not true.
The read/write speed of a mechanical hard drive has well-defined physical limits (at most, it is rotational speed * bytes per track * number of heads).
And even then, modern hard drives do not use more than 1 head at a time because it makes the drive significantly more complicated with little benefits compared to a RAID array.
The read/write speed of a large solid state disk is mostly limited by the controller design, not by the Flash chips.
Let's say we build a 256GB hard drive using 32GBit Flash chips, 20MByte/sec speed (which is quite slow by todays standard).
Using just 64 of such chips, we can design a device which does 1280MB/sec.
Free as in "beer".
Free as in "stolen".
You forgot:
Free as in "cheese".
The problem is that most consumer-level hardware is only tested with the most common TCP settings, so, changing the TCP receive window (RWIN) or maximum transfer unit (MTU) often reveals hidden bugs in their TCP/IP implementations.
Even the subtle changes in timing of the packets may trigger previously undiscovered bugs.
In my case, the web interface of the Acorp LAN420 ADSL router was 'freezing' 75% of the times when accessed from Vista(RTM). Upgrading to the latest firmware solved this problem.
If everything else fails, you can try disabling RWIN scaling by running this as administator:
netsh interface tcp set global rss=disabled
netsh interface tcp set global autotuninglevel=disabled
(to see the list of available options, just run 'netsh interface tcp set global')
Although there is no official word from Microsoft about Jet deprecation, Microsoft has stopped actively developing Jet.
There are numerous clues which may indicate Jet deprecation:
1. Jet is not ported to x64 platform, and probably will never be, according to MS devs.
You can only install 32-bit Jet 4.0 SP8 on an x64-based Windows OS.
Since Jet is an in-process component, it is not possible to use a Jet database in a 64-bit application.
2. Access 2007 uses its own, non-redistributable database back-end, codenamed Ace. Jet databases are supported only for legacy reasons.
3. Jet libraries have been removed from MDAC 2.8 package. You have to install Jet 4.0 separately.
4. Many newer MS articles and whitepapers suggest using SQL Server 2005 Express as opposing to Jet, as a superior technology.
Couldn't reproduce this with .txt - Notepad opens in my case (i'm using Word 2003).
.shs file may contain any ActiveDocument content. :)
Also, if you select something in Word and drag-and-drop it to a folder, a 'Scrap' file will be created with a hidden extension (.shs). This is one of the examples of ActiveDocument container dangers -
Another way to exploit the ActiveDocument vector is to use Insert->Object...->Word Document command in PowerPoint, Excel, and even Wordpad
So, even explicitly opening RTF's in WordPad is not perfectly safe.
While you definitely should not rely on extension filtering, if a Word document has a completely random extension, it will not open with Word by default. However, since Word classic .doc format is based on ActiveDocument and OLE Compound Storage format, you can embed Word content into quite a lot of files.
So, opening any OLE Compound Document by an application supporting Active Document (including Word itself) could be dangerous.
However, double-clicking on document.qwer is actually harmless, unless you choose Microsoft Word when prompted to select an application.
...you might also want the Killer Ethernet Cable.
When you buy your new 1GB video card (and they already exist), and wonder why only less than 3GB of 4GB of your physical memory is usable, you will really need an x64 OS.
(The fourth gigabyte can still be accessed with PAE if motherboard supports >32bit physical addresses, but PAE itself is an ugly kludge.)
Daemon Tools 4.06 run perfectly on my Vista RC2 x64 installation, without requiring me to disable 'driver signing enforcement' on bootup.
I had a similar problem when I was trying out SuSE Linux 9.1 x64 a couple of years ago.
The installation went OK, however, the keyboard never worked in GRUB, even if 'USB Legacy Support' was enabled. After some fiddling, I finally had to give up and use a PS/2 converter.
I think the problem is somehow related to the fact that the keyboard was not just a USB HID keyboard device, but a USB Composite device, containing two USB HID descriptors (a keyboard + a mouse).
The mouse descriptor is probably there because the keyboard has a scroll wheel, which works exactly like a mouse scroll wheel without installing any additional software.
NTFS design allows for 2^64 clusters.
Thus, with a 4096 byte cluster size, it can handle 2^26 Petabyte volumes.
The problem is that the current NTFS driver uses 32-bit integers to manipulate the cluster IDs - hence the 256 TB limit, using the largest supported cluster size (64KB).
I don't know about the x64 versions - probably the limit is still there because Microsoft doesn't care much about it at the moment.
It is possible to use MSHTML and not depend on any of IE's security settings - you just have to implement some additional interfaces in the application that uses MSHTML.
These are IInternetSecurityManager/IInternetZoneManager and also IInternetSecurityManagerEx/IInternetZoneManagerEx in Windows XP SP2.
I used MSHTML quite extensively, including running server-generated scripts from the HTML code and using the objects implemented by the host from those scripts. When done properly, IE security settings just don't affect any functionality.
Of course, relying on the default security manager to allow such behavior (like Symantec did) is stupid.
Actually, simple DVD-Rs and modified DVD player firmware could be used for that. :-).
Just make sure that the DVD player destroys the first few tracks (the TOC) before ejecting the DVD
And make the data format of the TOC slightly different so that the unmodified/unhacked firmware won't read these DVD-Rs.
One killer flaw, though - not every DVD player is also a DVD recorder.
Someone has just published all these bugs!
It is not a brand new IE feature, it is just a set of locked-down default security settings probably too harsh for average home user (a.k.a. 'Enhanced Security Configuration' - you can revert to WinXP default settings in 10 seconds if you want).
:).
This is reasonable on servers, but too restrictive to put that in Vista.
The ability to control (and disable by default) the loadable COM components without the Registry Editor (browsing through 1000's of COM GUIDs) is new in IE7, and that is a welcome improvement
Note: this functionality is NOT covered by the "Manage Add-ons" panel in XP SP2.
Good point about IObjectSafety in SP2. MS has raised the "bar" a bit further up by this, leaving old buggy code behind the bar.
However, if malware ever gets installed and gains admin access, it is quite pointless to defend against it.
Even the new IE7 opt-in system is going to be fooled - but *until* your system is rooted, you are in control of the COM components that can be used against you - and that's the point.
This, in fact, should reduce the IE's attack surface several-fold.
.VBS/.JS script stored on the local machine (which is trusted to do anything anyway), yet a lot of MS and third-party components is in CATID_SafeForScripting for no reason at all.
n /fq99-032.mspx n /fq99-037.mspx n /MS02-055.mspx n /MS02-065.mspx n /ms02-055.asp n /ms03-038.asp n /MS03-038.mspx e chnet/security/bulletin/MS03-038.asp
... and many-many-many more of these holes (just search for "kill bit" with the quotes)
MS has made a huge mistake when IE 4.x-6.x relied on CATID_SafeForScripting/CATID_SafeForInitializing COM component categories to make decisions whether it's safe to use the COM component from a JavaScript/VBScript.
CATID_SafeForScripting is not needed when the COM component is accessed from a stand-alone
IE has a kill bit feature which allows disabling certain scriptable COM components based on their GUIDs. And most IE security fixes are, in fact, just registry updates adding more of those "kill bits".
Examples: http://www.microsoft.com/technet/security/bulleti
http://www.microsoft.com/technet/security/bulleti
http://www.microsoft.com/technet/security/Bulleti
http://www.microsoft.com/technet/security/Bulleti
http://www.microsoft.com/technet/security/bulleti
http://www.microsoft.com/technet/security/bulleti
http://www.microsoft.com/technet/security/Bulleti
http://www.microsoft.com/technet/treeview/?url=/t
There have been speculations about all these 1207 pins in AMD's SocketM2 (due somewhere in 2006) will be used for an integrated PCIe controller.
http://www.theinquirer.net/?article=24756
The whole point of requiring the HDCP support in displays is to move from software obfuscation to hardware-imposed restrictions. ;)).
Neither the OS nor the applications running on it will be able to directly access an HDCP-protected stream, unless explicitly allowed to (in theory
HDCP is just an evil feature of HD-DVD/Blu-Ray, and Microsoft just adds the OS-level support for this stuff.
So, in fact, there could be an opportunity for an open and legal implementation of HDCP on Linux.