First of all, the DOC format (the original Word formats) are not open, only DOCX are somewhat open.
Oh please! The DOC format is not open in the sense that anyone can contribute. But the documentation of the format is fully available for anyone who take interest. It merely requires a single google: http://www.microsoft.com/interop/docs/OfficeBinaryFormats.mspx
DOCX is fully open. Anyone who wants to contribute is free to do so. You just have to go through ECMA/ISO - just like Microsoft. It is fully described in the ISO standard ISO/IEC 29500. The standard is freely downloadable from ISO. If you had cared to download it you would have found that your claims are BS:
The problems are in: charts, styles, watermarks, fonts, tracked changes, and SmartArt.
Charts, watermarks, tracked changes and SmartArt are not open/documented in the OOXML formats.
Charts are part of DrawingML and described in section 21.2 Charts.
Watermarks are described as part of the document settings/template feature. See section 11.1
Tracked changes for DocumentML is described in full in section 17.13.5 Revisions. Similar sections exists for e.g. SpreadsheetML.
The built-in SmartArt gallery is not part of the standard. But any SmartArt "chart" is just a DrawingML part with a datamodel, both of which are described in sections 14 and 21. It is not like the graphics are intermingled with the data in such a way that others have no way of figuring out what's going on. SmartArt is the term used for the manipulation of such graphics. At all times the "data" is kept separate from the graphics and the end-graphics is the result of a transformation. A transformation which is fully described in the standard.
Styles and fonts (assuming you mean text styles in Word) are described in section 17.7 Styles and 17.8 Fonts
Use a reputable antivirus/antimalware suite. (You probably already do)
Never allow users to run as admins on the boxes. If some user types must be able to do so (like developers), isolate those in a separate OU for which you can design specific policies.
Use a WSUS server which will let you control which patches are available. Instead of evaluating/testing if/when to allow a patch through, consider segmenting the clients/servers and do a gradual rollout of all patches (like 15% the first day (tuesday), 35% the next day and the rest on the 3rd day). This will lower the risk of a bad patch messing everything up but will ensure a fast rollout.
Use Network Access Protection (only available for Vista/7 clients IIRC). This is a service which will use an agent program to ensure that the client meets certain policies, like patch level. The clients which do not meet requirements should be quarantined and only allowed to download from the WSUS server. This way you can ensure that old machines do not suddenly appear on the network in an unpatched state.
Use Windows 7 or Vista clients. These have much better protection against e.g. memory corruption bugs and supports integrity level for e.g. Internet Explorer 7+ and Chrome.
Use Chrome or IE8 as browsers. Both are designed with proper sandboxing ind mind. IE8 is more AD-policy friendly and can be locked down pretty tightly. Chrome is less of a target but is somewhat harder to manage in an enterprise.
Consider an OU for "vanilla users" with a policy which includes Applocker rules. With Applocker you can whitelist applications signed with certain signatures to execute and prevent all others. I.e. you can allow digitally signed MS, Adobe, Apple, Google apps to execute and bar all others. In-house apps can be self-signed (no need to buy an expensive cert).
Filter dangerous content at the firewall, e.g. block "executable content". Consider subscribing to a reputation service which can block pr0n and warez sites etc.
Lastly, for the ultimate in client resilience, consider deploying Microsoft SteadyState. With SteadyState you can set up policies to virtualize harddisks so that any change to the system partition will be reverted on every reboot. It can still be set to allow automatic patching.
I know that I probably shouldn't feed the troll, but anyway
Windows does not "break consistently". (what is that anyway?). I assume you meant "constantly". But that would also be false. Windows has grown rock solid, and since XP and with Vista/7 you will only ever experience BSODs when a driver or hardware malfunctions badly.
MS has grown wary of bundling applications. Those 92% market share means that any bundled app is a potential anti-trust suit. MS' new policy is to make apps available for downloading, such as movie maker etc. If you are referring to apt-get, then you're right, MS doesn't have anything like that.
Single desktop. I'm not sure why you believe fragmentation would be desirable. Anyways, Windows allows the desktop "shell" to be replaced - as it often is in kiosk apps etc (when they are not running Linux).
When was the last time you updated Ubuntu? In my experience that OS needs a lot more patching than Windows. All OSes need patching. Live with it.
No, the graphics are not as pretty as - say - OS X. And certainly not as overloaded (or stunning) as compiz. But the effects *are* carefully thought through and tends to not distract from the main purpose. Live preview is really useful. As are jumplists. The matte glass effect is just bling, rarely useful.
No, it doesn't appear so at this time. But it could be.
I mean how the hell do you get the pointer in the first place? And how do you keep the browser from page faulting?
I'm so confused!
The attacker actually don't "get the pointer". He discovered some bug where IE would deallocate an object but still hold a pointer to it. A "dangling" pointer.
The attacker then typically allocates *a lot* of other objects, hoping that they will take up the address pointed to by the "dangling" pointer. He will try to arrange the allocations such that the allocated "data" is actually attack code if ever executed as instructions. The attacker could hide attack code in string constants/buffers etc.
Then he proceeds to prompt IE to actually *follow* the dangling pointer. If he's lucky (and skillful) IE will now hit something which was actually "data" - but when executed as CPU instruction it is actually malicious attack code.
This is why DEP will kill this attack. As soon as the CPU is jumping into a NX memory block, it faults. And the heap/stack are marked as NX (DEP) in all recent MS OSes for IE8.
It states pretty clearly that IE7 *may* be vulnerable to this attack. But it also states that IE8 - on all recent platforms (XPSP3, Vista, 7) - contains the bug but due to DEP (and protected mode on Vista/7) it is not exploitable. That seems to be a pretty good reason to upgrade.
They don't seem to be known for exaggerating the vulnerability of their software. I'm sure I'm missing something here, I'm just sincerely not seeing why Microsoft would claim it would affect IE8 if they could make the opposite claim with any accuracy.
Actually, Microsoft has a policy of not taking protected mode, low integrity processes, DEP/NX, ASLR and other memory corruption protection mechanisms into consideration when assigning severity levels or reporting bugs.
This means that MS reports the bug as being in IE8, but the several layers of extra protection in both IE8 and Vista/7 may very well neuter it completely.
FF3 and IE8 are about the same age. In the same time frame FF3 has raked up 144 vulnerabilities. IE8 has experienced 23.
And no, those FF bugs are not just trivialities. They are practically all of them rated "highly critical". And most of them are - tada - memory corruption bugs like the one exploited in this attack.
#1) It's impossible to conclusively make this statement since we don't have access to Microsoft's internal bug tracker.
#2) The directly comparable indicators we do have (how many major exploits are actually published) do not agree with your statement.
#3) Your statement ignores one other key factor: The time it takes the vendor to fix the bug. Who cares is a browser has only one major security exploit per year if it takes two years for the vendor to fix it? At that point, your ass is always hanging out in the wind.
#1) We have access to Microsofts Security Bulletins - which are among the most detailed in the industry. Admins depend on those bulletins to be accurate. They need to make the right decisions on whether to block or allow patches. What do you think would happen if MS tried to sneak a patch by and it turned out to cause damage to systems? Simply put, there's nothing to support a suggestion that MS is sneaking anything by.
#2) Number of exploits is a function of profitability, is has no correlation to number of security bugs or software quality. One bug may give rise to many exploitation attempts. 144 vulnerabilities may never be exploited. Consider two lotteries, tickets the same price and the winning chances were same. Only in one lottery the prizes were 10x bigger. Given you could buy 10 tickets - how would you spend them?
#3 Time to fix is relevant. However, in this case it doesn't matter, because this was targeted attacks. Somebody had put in a lot of effort in finding a bug and prepare a cocktail attack (social engineering, pdf and IE). This was not a publicly disclosed bug. No vendor can patch a bug before they know of it. Simply put, the most important precaution is to up the QA standards and prevent the bugs in the first place. Then - when a bug is eventually discovered - it is important to fix it fast.
Mozilla certainly seems to patch fast. But they have 8 times more bugs to fix. That says something about their quality control as compared to Microsofts. Which shouldn't come as a surprise given how crash-happy Firefox has become.
Disclosure: I use Chrome. Safer and far less crash-happy than FF.
Actually, this is a design problem in Java and possibly JavaScript and.NET as well. The problem is that an attacker can design a "perfectly legal" Java applet. Only it may contain mostly string constants. Constants whose binary representation is actually machine code.
By "spraying" instances of such an applet all over the memory (by asking the browser to instantiate it) it will fill up the memory with strings constants. They are perfectly legal *from a Java perspective*. But if some kind of memory corruption (doesn't have to be in Java) bug sends the program counter astray, the attacker *may* just hit one of those strings - and now the CPU starts executing them as if they were code. That's what is meant when Java is referred to as a stepping stone. Formally this is not a Java problem. Java didn't cause the memory corruption. Java never started executing strings. It was merely a well intentioned assistant.
Similar problems have been reported with Javascript in certain browsers. And at some point.NET assemblies were dangerous this way as well. Only the Java problem is slightly more unique in that it uses a hotspot compiler. *First* it executes bytecode - which from the CPU perspective is just data. When a certain region of code is hit a little too often it will compile that region into executable code on the fly. It follows that Java *can write code* which it will then execute. This is a downright dangerous design. There are ways around it, see the response from TheRaven furter up.
DEP would have prevented the specific attack. Protected mode would have severely restricted the impact of a successful exploit.
But DEP is not the end-all solution. It is a significant barrier to exploiting memory corruption bugs, but with 3rd party software involved there is always the risk that the attacker could use those as stepping stones. Java is always a risk in this regard because of its hotspot compiler nature and a bad habit of placing string constants alongside code. Because of the hotspot technology and because it must execute in-process, Java inherently has the ability to both write and execute code..NET always executes fully compiled and the code blocks are read-only. However, there was a bug (now patched) whereby an attacker could misrepresent the version of an assembly and cause.NET to "nicely" allow an attacker execute string constants.
The Vista/7 low-integrity process is effectively a sandbox. It works by dropping the rights of the process so low that IE cannot write *anywhere* on the system, except for a secluded cache store. To my knowledge this has *never* been broken. Again, 3rd party/external software may be the weak links. At a pwn2own an attack successfully circumvented the sandbox by exploiting a bug in a Flash helper process which executed *outside* the sandbox. Another vector seems to be pdf because the pdf reader is *also* running outside the sandbox with "normal" integrity level. The IE broker process which helps marshal downloads have never been broken.
Considering that certain other browsers (Firefox and Safari) experience many more security bugs these days, combined with the fact that none of these offer sandboxing, the recommendation does seem a bit odd.
Especially in the light of Microsoft's bulletin which makes it very clear that this particular bug would be prevented by *both* DEP as well as protected mode.
On Windows creating a process is a relatively expensive operation, while creating a thread is comparatively very fast.
Internet Explorer actually uses threads for tabs, not processes like Chrome. On Windows, processes are not units of execution, rather they are resource boundaries, i.e. the process contains security tokens, memory and other resources. A process will always have at least one thread (the unit of execution).
The advantage of using multiple threads (one per tab) is that you get some insulation from bugs (hangs, security violations, etc), but if memory is corrupted the entire process is compromised. All IEs tab threads execute within a sandboxed process (running with "low" integrity level) which prevents the threads from writing anywhere on the system except for some cache storage (the location of which is obfuscated to avoid social engineering tricks).
Chrome uses multiple processes (one rendering process per tab). Hence it has even better isolation: Even if a tab (or - more commonly - a plugin used from within a tab) misbehaves and corrupts memory, the *other* tabs will not be affected.
Clearly, the process-per-tab has an advantage in robustness over thread-per-tab. But it also (theoretically) uses more resources. I use Chrome as my main browser and I don't think the resource overhead is an issue.
Me too. But what does this tell you about the priorities at the IE team when this is something worth bragging about?
I saw a video from PDC (can't find it anymore) and it clearly demonstrated why they are focusing on Direct2D sub-pixel rendering: Performance and visual appearance.
Direct2D is hardware accelerated and offers much higher frame rates (with less CPU utilization) when animating using JavaScript. The sub-pixel rendering proved its worth when animating text that slowly grew bigger. The non-sub-pixel rendering was jittery because the glyphs aligned to full pixels before jumping to the next full pixels. It is hard to explain, but it was very much the same feeling as when someone strikes a wrong chord compared to the smooth Direct2D animation. It was very, very evident.
The future is animations and - if it is not Flash or Silverlight - they will be handled by the browser, possibly in JavaScript. If I get a much smoother "feeling" using browser A compared to a "jittery" experience with browser B, that may influence my choice somewhere down the line (right now my choice is Chrome).
In the same presentation MS also showed graphs from Sunspider benchmark on the early internal IE9 builds - and it actually comes quite close to Chrome (although still last). So they are also working on Javascript performance.
The team *also* showed some telemetry data and statistics from some real-life webpages. On some "javscript heavy" pages JavaScript accounts for a good 30% of the total elapsed time (the rest goes to layout, rendering, network, latency etc.). On other sites the JavaScript share was negligible.
That is why it makes sense to focus on performance in other areas as well. The current "mine is bigger than yours" Sunspider competition is missing the point. It doesn't matter if you have a JavaScript engine that is 2x faster than the nearest competitor if you waste an equal amount of CPU on rendering or layout.
I'm working with TFS on a daily basis and I am thoroughly impressed - with the possible exception for the code "merging" tools. I am curious, what "nice, high quality open source solution" would be an alternative? This is not a jab or anything, but using TFS was the first time I realized how much an integrated source control, team collaboration site, project management integrated solution makes sense.
So, is there an open source integrated solution or combo which will meet the following requirements?
Integrated work items with specialized and extensible work item types for tasks, bugs, issues etc.
Configurable policies which e.g. demands (or not) a work item reference when checking out and/or checking in.
Work items, tasks, issues etc. editable through a web interface, but also right from inside the IDE.
Work items, tasks, issues etc. editable through Excel or some other spreadsheet (regrettably project managers favorite tool is *still* Excel - but having it integrated so the rest of us don't have to mock around inside columns and rows to update status is a big relief).
Source control without quirks when e.g. renaming files or removing files and adding files back with the same names (I've had bad experience with subversion)
Shelving - storage of not-completed changes on the server without checking in. We use it to share suggestions and if we cannot make the daily deadline on consistent checkins.
Configurable policy which can be set to reject commits/checkins if a build has not been completed locally and/or if too many tests fails and/or if test coverage is too low and/or if there are too many/certain warnings (e.g. security related).
Dashboard with project manager-friendly rollups and graphs with speed, test coverage, test completions, tasks, status etc.
Branching based on metadata - not on actual directory copying and separate repositories/directories on the server (goes to performance).
For example, the entire ASP.NET API suffers from a similar mismatch of encodings flaw: All of the data binding controls fail to properly HTML encode strings coming from a database.
In fact, ASP.NET has some very sensible options for addressing this issue. Take for example the (infamous) DataGrid. In DataGrid you define columns. The column to "bind" to a datasource (database/collection/etc) is called BoundColumn. It has a property called HtmlEncode. It has a default value of true. Which means that contrary to your claim, if you use this "data binding" control, ASP.NET *will* encode data bound text by *default*
The Literal control is just that. It defaults to displaying literal text. However, it *also* has a property so set whether to pass-through, encode or translate html.
It is true that some controls (like e.g. RadioButtonList) do not support encoding the *text* property. Those controls render in a way where you should never set anything but plain text anyway. If you were binding HTML text to radiobutton lists, checkbox lists or select controls I suggest you take a good long look at the requirement instead.
The one time I wrote an ASP.NET app, I had to spend weeks going through and replacing all of the simple-looking bind statements with explicit calls to a method that would both bind and encode.
Sorry, but that is just stupid. You should simply have set the encode property of the control you were binding to instead. If you were binding to a control which did not expose such a property, maybe you should have used a control which did?
If you've only ever written a single ASP.NET application, perhaps you refrain from making bold faced criticism on a subject where you are obviously not qualified.
Even in the upcoming 4.0 release, the flaw is still there. I suspect that it won't ever get fixed.
No, it will not be fixed, because it is a feature, not a flaw. This is a case of an unexperienced developer misunderstanding the framework and failing to use the correct components. But there's a fix for that, too.
All studies analyzing security vulnerability reports or released patch sets as a measure of OS security simply prove that the researcher is a fucking idiot. It's IMPOSSIBLE to measure security in this way because you are comparing lawn tractors to jet skis.
That is right. It is much better to rely on Apple adds to get the "real picture". Because we all just "know" that OS X is secure by design, that it is immune to viruses and stupid users.
Instead of any form of metric let's just vote who's secure and who's not. Better yet - let's leave it to the blogosphere and biased forums.
Or maybe you should read the IBM report on "the economics of exploits".
Yeah, I've read this "market share" argument used as a defense for shoddy MS code time and time again. That just doesn't cut it.
So you think that an attacker thinks he must exploit each platform proportional to the market share?
Or do you believe that each attacker randomly chooses a platform to specialize in proportional to market share. Or do they keep a list with number of slots according to each OS's market share?
Consider this:
Imagine you were on a shooting range. You can shoot for two different targets, one labelled "OS X" and the other one "Windows"
One "OS X" target is 3 times larger than the other (OS X has 3 times the vulnerabilities compared to Windows) and is thus easier to hit.
Each time you hit "OS X" you get $10.
Each time you hit "Windows" you get $200.
You have 12 shots.
Now, if the targets were 10 ft in front of you and both easily hit, how would you spend your 12 shots? Would you aim 3 shots that the smaller target and 9 shots at the larger target because that seems the fair thing to do? Or would you just shoot all 12 shots at the smaller target and go home with $2400? I know what the typical person would do.
Only when you move both targets so far back that both of them gets pretty hard to hit would any sane person consider spending any rounds on "OS X".
Attackers chose target platform based this simple economics. As long as Windows has 15 - 20 times (worldwide) the market share of OSX and as long as the limiting factor of attacks is time (the actual creation of an exploit), the attackers are going to target Windows each and every time. Only if they cannot find any exploitable vulnerabilities in Windows will they invest in another platform.
Oh, and what about Apache you say? Apache has 2 times the market share of IIS (roughly). Why isn't Apache attacked exclusively for the same reason. The difference here is that these targets are pretty distant; both Apache and IIS are pretty tight. Neither Apache nor IIS5, 6 and 7 has seen successful widespread attacks directly at the server. Neither Linux nor Windows are vulnerable at the network level anymore, especially not when behind a firewall as *all* webservers are nowadays.
The shooters have simply given up (for the time being) and went to another shooting range with better odds. BothApache and IIS has seen widespread attacks against vulnerable applications running on top of the servers. Here you could certainly argue that attackers has a preference for PHP and ASP.Ancient.
Look under "most vulnerable operating system".
Yes, right at the top, for several years going sits OS X. It actually consistently experiences 3 times the number of vulnerabilities compared to Vista.
You can also do some secunia digging yourself. It shows the same tendency even in the raw data.
OS X may be less exploited but it has far more vulnerabilities. On top of that OS X lacks many of the anti-exploit mechanisms found in both common Linux distros and in Windows Vista.
Vulnerabilities does not have much to do with exploits. A single vulnerability may leads to several independant exploits. Many vulnerabilities will pass unexploited. The difference is incentive. And if pwn2own has showed us anything it certainly confirms this. Macs have consistently been the first to fall, literally within seconds.
On the other hand, if you know a free way to do it, I'd be interested in hearing it. To my knowledge there is none.
There most certainly is. Just copy the files over to the designated directory on the webserver. It will even detect the changes and gracefully restart the webapp with no service interruption. IIS with ASP.NET installed has everything it needs to compile C# and VB.NET source files, ASP.NET markup etc. It will recognize any assemblies put into the apps/bin folder as well.
If you feel uncomfortable deploying source files and prefer to precompile,.NET comes with a tool called aspnet_compiler. This is a commandline tool and actually builds upon the same code which is invoked during a Visual Studio "deploy".
You don't need Visual Studio at all to develop ASP.NET solutions. You can deploy or compile without it. Not recommended, but entirely possible. This is actually what many big shops do on their build servers.
IIS comes with any version of Windows (server). The cheapest "web" edition of Windows server is listed as $469 and it is perfectly capable of running most corporate websites.
Here's what I wonder when people advocate using all available RAM for running programs: what happens when I try to launch another program ? Parts will have to be swapped out, and again when the new program has a genuine need for more memory.
Some parts will not have to be swapped out. If the memory is not "dirty" it can just be deallocated. This is how Windows has handled dll's for ages: If a loaded dll code block made it to the front of the "standby" list it could just be discarded as loading the memory from the dll file could always be done.
Incidently, Windows Vista improved on this scheme and introduced memory priorities. This way an application - even a user-mode process - can happily consume RAM to improve its performance. If it marks the memory with a low priority and "non-dirty" (because it has a way to reload it in a fail-safe way) it *will* just be discarded when another process needs memory. On top of that, lower priority allocations will never cause higher prioritized memory to be swapped out.
Applications should use the amount of memory they need, preferably leaving caching to the operating system. Applications generally cannot know when other processes need the RAM better, and AFAIK cannot be told to release memory by other applications in any standardized way.
That may be so for most operating systems, but since Vista, Windows apps can assign memory priorities to their allocated memory. This was introduced to counter the after lunch syndrome where a memory intensive process (e.g. a search indexer that springs into action on idle conditions) has evicted all your procceses memory while you were eating. Processes can also register to be notified when their memory is evicted and may choose to just drop the memory instead of having it swapped to disk.
A process such as Windows Defender or the search indexer can now allocate memory with a lower-than-normal priority. This will not cause higher prioritzed memory to be swapped out and this memory will be the first to be evicted when higher-priority memory is allocated.
Windows Superfetch is an example of a user-mode process which leverage this memory infrastructure to allocate memory in a speculative manner. If memory is allocated with a higher priority, Superfetch readily gives up the memory with no additional disk access.
So while most operating systems indeed do not have a standardized way to tell applications to give up memory, this is exactly what Windows Vista, Server 2008 and later feature.
chkdsk.exe is a disk checking and file-system repair tool. Most users will never know about it.
The chkdsk functionality kan be invoked through Windows Explorer as well. Some users will find this tool if they deliberately are looking for it.
chkdsk.exe with the/r oprion (and *only* with the/r option) has been designed to allocate most of the available physical memory, but always leave at least 50M free. This is not a memory leak. It was a deliberate decision because using more memory will dramatically speed up the surface verification/repair process. Note, it will allocate from available memory, i.e. already allocated memory will not be forced out into paged/virtual memory. If this was a leak the allocation would go on and on, cause more and more swapping until the system trashed itself to death. But it's not. The system remains responsive and the memory is freed when chkdsk ends.
The crash condition appears to be an unrelated issue with chipset controller drivers. Propably this issue becomes more pronounced during periods with intensive disk usage and/or low memory conditions. It is not caused by chkdsk, it is a driver/controller issue which has been reported to be fixed by updating drivers to the latest version.
No, the real issue is that Microsoft appears to be slated for a massive success with Windows 7. At this point some Microsoft detractors will leap upon any issue in an attempt to spoil the party. In this category you find Randal C. Kennedy of InfoWorld who leapt on to this issue with blatant disregard for any facts.
Even if the original blogger and mr. Kennedy were so stupid as to believe this issue was a memory leak and that it caused the crash, by their own account it would only manifest itself under very specific circumstances:
chkdsk.exe must be invoked with the/R option to perform a surface scan/repair (this is the most radical option).
chkdsk.exe must be invoked for a non-system partition (chkdsk must dismount the drive/partition - using/r on the system drive requires chkdsk to run during boot instead).
So, even if this was a bug, only users with
2 or more drives/partitions,
one non-system exhibiting suspicious behavior to warrant a "surface scan".
users able to find and launch the tool
No, this whole bruhaha has a distinct smell of desperation about it. And kdawson is - as usual - all to happy to assist.
MS isn't improving the performance or security of their operating system.
Huh? Windows Vista introduced some really low level:
Memory and IO priory - which made background tasks less interfering as they could gradually cause higher memory priorities to be swapped even if you left the machine idle for a long time
Granular scheduler - more precise scheduling
Multimedia-aware scheduling - network bandwidth reserved when playing back multimedia and cpu and memory reserved to avoid glitches. Vista (and 7) holds up remarkbly well under stress - much more than Xp or Linux.
It is widely recognized (at least among security researchers such as Charlie Miller) that Vista has improved security a great deal:
Stack/heap encryption and checksumming
DEP
Variable reordering (making buffer overflows much less likely to affect critical parts with pointers)
Many other anti-memory-corruption prevention mechanisms
Process integrity levels and the IE sandbox - effectively a subdivision of the current user account by modifying the process security token (dropping rights) and preventing shatter attacks.
Service hardening - even before Vista/Server 2008 only a few services (daemons) were actually running as the "root" (SYSTEM) account. But with Vista/2008 service hardening again modifies the process security token to effectively shut it out from any resources except those explicitly granted. This is like Apparmor, only it leverages the built-in granular permission structure instead of requiring external "profiles". In other words, it is like each service has it's own account and has severely restricted access - even if formally running as SYSTEM or NETWORK SERVICE.
Network Access Protection - can (almost) guarantee that clients on a network which do not meet certain policy requirements (e.g. patch levels, AV protection etc.) are quarantined and only allowed e.g. windowsupdate access.
Windows 7 also has some kernel tweaks which further improves performance and scalability
Microsoft engineers solved the "spinlock" problem (akin to the "big kernel lock" problem Linux still grabbles with) and improved performance and scalability to 256 cores.
Concurrency and Coordination Runtime (to be backported IIRC) which is a highly granular, minimal-overhead user mode threading model. Programs written to take advantage of these features will have greatly improved scalability across many-cores (the current process/thread concept for concurrency is really coarse-grained in comparison).
Transactional memory (at least they are experimenting with it in '7).
New "delayed" service mode
Multicore tweaking - switch off entire cores when usage so permits to save energy.
Lots of other minor tweaks - such as consolidating timer events so that if processes asks for timer events every 10 seconds they are synchronized so that they all receive their event at the same time and the CPU can go into a lower energy state in between.
Intel and AMD have been making dual-core CPUs for more than FOUR YEARS.
What your point? All major operating systems have supported multiple cores FOR YEARS. Even XP had support for 2-4 cores IIRC. The article you linked to was not an announcement that Windows now can use multiple cores, it was an announcement of the new tweaks (removal of spinlock and 256 core scalability) and of the new Concurrency and Coordination Runtime (a.k.a. "concert") - which is user mode threading and is in addition to the traditional kernel mode threading with processes and threads.
Um, wait. Mono is said to be a free as in speech implementation of C#, but aren't the codecs, which are what really matters for watching video, still proprietary? (Not a rhetorical question; I'd really like to know.)
Yes, many of the codecs (all?) aren't even Microsoft property. Rather they are the IP of 3rd party codec developers often incumbered by patents.
Microsoft has licensed these commercial codecs with the right to re-distribute from the MS websites. This allows MS to use them in Silverlight.
Microsoft also entered into an agreement with Novell (and by extension the Mono project) to make the codecs available to Mono users as well. But to avoid violating MS license with the IP holders the Mono users are required to download the codecs from the MS website.
This is nothing sinister. The codecs were never Microsofts to hand over in the first place. The end result is almost the same: Mono/Moonlight users get access to the codecs with only a minor added inconvenience.
Of course, the codecs are still not *free* as in speech. Only the original IP holders can set them free. And it will probably be a cold day in hell before that happens.
Slashdot Mirror
First of all, the DOC format (the original Word formats) are not open, only DOCX are somewhat open.
Oh please! The DOC format is not open in the sense that anyone can contribute. But the documentation of the format is fully available for anyone who take interest. It merely requires a single google: http://www.microsoft.com/interop/docs/OfficeBinaryFormats.mspx
DOCX is fully open. Anyone who wants to contribute is free to do so. You just have to go through ECMA/ISO - just like Microsoft. It is fully described in the ISO standard ISO/IEC 29500. The standard is freely downloadable from ISO. If you had cared to download it you would have found that your claims are BS:
The problems are in: charts, styles, watermarks, fonts, tracked changes, and SmartArt.
Charts, watermarks, tracked changes and SmartArt are not open/documented in the OOXML formats.
Charts are part of DrawingML and described in section 21.2 Charts.
Watermarks are described as part of the document settings/template feature. See section 11.1
Tracked changes for DocumentML is described in full in section 17.13.5 Revisions. Similar sections exists for e.g. SpreadsheetML.
The built-in SmartArt gallery is not part of the standard. But any SmartArt "chart" is just a DrawingML part with a datamodel, both of which are described in sections 14 and 21. It is not like the graphics are intermingled with the data in such a way that others have no way of figuring out what's going on. SmartArt is the term used for the manipulation of such graphics. At all times the "data" is kept separate from the graphics and the end-graphics is the result of a transformation. A transformation which is fully described in the standard.
Styles and fonts (assuming you mean text styles in Word) are described in section 17.7 Styles and 17.8 Fonts
I know that I probably shouldn't feed the troll, but anyway
Is this an ActiveX thing?
No, it doesn't appear so at this time. But it could be.
I mean how the hell do you get the pointer in the first place? And how do you keep the browser from page faulting?
I'm so confused!
The attacker actually don't "get the pointer". He discovered some bug where IE would deallocate an object but still hold a pointer to it. A "dangling" pointer.
The attacker then typically allocates *a lot* of other objects, hoping that they will take up the address pointed to by the "dangling" pointer. He will try to arrange the allocations such that the allocated "data" is actually attack code if ever executed as instructions. The attacker could hide attack code in string constants/buffers etc.
Then he proceeds to prompt IE to actually *follow* the dangling pointer. If he's lucky (and skillful) IE will now hit something which was actually "data" - but when executed as CPU instruction it is actually malicious attack code.
This is why DEP will kill this attack. As soon as the CPU is jumping into a NX memory block, it faults. And the heap/stack are marked as NX (DEP) in all recent MS OSes for IE8.
Microsoft's advisory admits that both IE7 and IE8 are vulnerable to the same flaw, even on Windows 7.
That is a misrepresentation, at best.
The knowledge-base article: http://blogs.technet.com/srd/archive/2010/01/15/assessing-risk-of-ie-0day-vulnerability.aspx
It states pretty clearly that IE7 *may* be vulnerable to this attack. But it also states that IE8 - on all recent platforms (XPSP3, Vista, 7) - contains the bug but due to DEP (and protected mode on Vista/7) it is not exploitable. That seems to be a pretty good reason to upgrade.
They don't seem to be known for exaggerating the vulnerability of their software. I'm sure I'm missing something here, I'm just sincerely not seeing why Microsoft would claim it would affect IE8 if they could make the opposite claim with any accuracy.
Actually, Microsoft has a policy of not taking protected mode, low integrity processes, DEP/NX, ASLR and other memory corruption protection mechanisms into consideration when assigning severity levels or reporting bugs.
This means that MS reports the bug as being in IE8, but the several layers of extra protection in both IE8 and Vista/7 may very well neuter it completely.
What a bunch of crap!
Ignored.
Where's your proof?
Here: http://secunia.com/advisories/product/19089/
and here: http://secunia.com/advisories/product/21625/
FF3 and IE8 are about the same age. In the same time frame FF3 has raked up 144 vulnerabilities. IE8 has experienced 23.
And no, those FF bugs are not just trivialities. They are practically all of them rated "highly critical". And most of them are - tada - memory corruption bugs like the one exploited in this attack.
#1) It's impossible to conclusively make this statement since we don't have access to Microsoft's internal bug tracker.
#2) The directly comparable indicators we do have (how many major exploits are actually published) do not agree with your statement.
#3) Your statement ignores one other key factor: The time it takes the vendor to fix the bug. Who cares is a browser has only one major security exploit per year if it takes two years for the vendor to fix it? At that point, your ass is always hanging out in the wind.
#1) We have access to Microsofts Security Bulletins - which are among the most detailed in the industry. Admins depend on those bulletins to be accurate. They need to make the right decisions on whether to block or allow patches. What do you think would happen if MS tried to sneak a patch by and it turned out to cause damage to systems? Simply put, there's nothing to support a suggestion that MS is sneaking anything by.
#2) Number of exploits is a function of profitability, is has no correlation to number of security bugs or software quality. One bug may give rise to many exploitation attempts. 144 vulnerabilities may never be exploited. Consider two lotteries, tickets the same price and the winning chances were same. Only in one lottery the prizes were 10x bigger. Given you could buy 10 tickets - how would you spend them?
#3 Time to fix is relevant. However, in this case it doesn't matter, because this was targeted attacks. Somebody had put in a lot of effort in finding a bug and prepare a cocktail attack (social engineering, pdf and IE). This was not a publicly disclosed bug. No vendor can patch a bug before they know of it. Simply put, the most important precaution is to up the QA standards and prevent the bugs in the first place. Then - when a bug is eventually discovered - it is important to fix it fast.
Mozilla certainly seems to patch fast. But they have 8 times more bugs to fix. That says something about their quality control as compared to Microsofts. Which shouldn't come as a surprise given how crash-happy Firefox has become.
Disclosure: I use Chrome. Safer and far less crash-happy than FF.
Actually, this is a design problem in Java and possibly JavaScript and .NET as well. The problem is that an attacker can design a "perfectly legal" Java applet. Only it may contain mostly string constants. Constants whose binary representation is actually machine code.
By "spraying" instances of such an applet all over the memory (by asking the browser to instantiate it) it will fill up the memory with strings constants. They are perfectly legal *from a Java perspective*. But if some kind of memory corruption (doesn't have to be in Java) bug sends the program counter astray, the attacker *may* just hit one of those strings - and now the CPU starts executing them as if they were code. That's what is meant when Java is referred to as a stepping stone. Formally this is not a Java problem. Java didn't cause the memory corruption. Java never started executing strings. It was merely a well intentioned assistant.
Similar problems have been reported with Javascript in certain browsers. And at some point .NET assemblies were dangerous this way as well. Only the Java problem is slightly more unique in that it uses a hotspot compiler. *First* it executes bytecode - which from the CPU perspective is just data. When a certain region of code is hit a little too often it will compile that region into executable code on the fly. It follows that Java *can write code* which it will then execute. This is a downright dangerous design. There are ways around it, see the response from TheRaven furter up.
DEP would have prevented the specific attack. Protected mode would have severely restricted the impact of a successful exploit.
But DEP is not the end-all solution. It is a significant barrier to exploiting memory corruption bugs, but with 3rd party software involved there is always the risk that the attacker could use those as stepping stones. Java is always a risk in this regard because of its hotspot compiler nature and a bad habit of placing string constants alongside code. Because of the hotspot technology and because it must execute in-process, Java inherently has the ability to both write and execute code. .NET always executes fully compiled and the code blocks are read-only. However, there was a bug (now patched) whereby an attacker could misrepresent the version of an assembly and cause .NET to "nicely" allow an attacker execute string constants.
The Vista/7 low-integrity process is effectively a sandbox. It works by dropping the rights of the process so low that IE cannot write *anywhere* on the system, except for a secluded cache store. To my knowledge this has *never* been broken. Again, 3rd party/external software may be the weak links. At a pwn2own an attack successfully circumvented the sandbox by exploiting a bug in a Flash helper process which executed *outside* the sandbox. Another vector seems to be pdf because the pdf reader is *also* running outside the sandbox with "normal" integrity level. The IE broker process which helps marshal downloads have never been broken.
Considering that certain other browsers (Firefox and Safari) experience many more security bugs these days, combined with the fact that none of these offer sandboxing, the recommendation does seem a bit odd.
Especially in the light of Microsoft's bulletin which makes it very clear that this particular bug would be prevented by *both* DEP as well as protected mode.
On Windows creating a process is a relatively expensive operation, while creating a thread is comparatively very fast.
Internet Explorer actually uses threads for tabs, not processes like Chrome. On Windows, processes are not units of execution, rather they are resource boundaries, i.e. the process contains security tokens, memory and other resources. A process will always have at least one thread (the unit of execution).
The advantage of using multiple threads (one per tab) is that you get some insulation from bugs (hangs, security violations, etc), but if memory is corrupted the entire process is compromised. All IEs tab threads execute within a sandboxed process (running with "low" integrity level) which prevents the threads from writing anywhere on the system except for some cache storage (the location of which is obfuscated to avoid social engineering tricks).
Chrome uses multiple processes (one rendering process per tab). Hence it has even better isolation: Even if a tab (or - more commonly - a plugin used from within a tab) misbehaves and corrupts memory, the *other* tabs will not be affected.
Clearly, the process-per-tab has an advantage in robustness over thread-per-tab. But it also (theoretically) uses more resources. I use Chrome as my main browser and I don't think the resource overhead is an issue.
Me too. But what does this tell you about the priorities at the IE team when this is something worth bragging about?
I saw a video from PDC (can't find it anymore) and it clearly demonstrated why they are focusing on Direct2D sub-pixel rendering: Performance and visual appearance.
Direct2D is hardware accelerated and offers much higher frame rates (with less CPU utilization) when animating using JavaScript. The sub-pixel rendering proved its worth when animating text that slowly grew bigger. The non-sub-pixel rendering was jittery because the glyphs aligned to full pixels before jumping to the next full pixels. It is hard to explain, but it was very much the same feeling as when someone strikes a wrong chord compared to the smooth Direct2D animation. It was very, very evident.
The future is animations and - if it is not Flash or Silverlight - they will be handled by the browser, possibly in JavaScript. If I get a much smoother "feeling" using browser A compared to a "jittery" experience with browser B, that may influence my choice somewhere down the line (right now my choice is Chrome).
In the same presentation MS also showed graphs from Sunspider benchmark on the early internal IE9 builds - and it actually comes quite close to Chrome (although still last). So they are also working on Javascript performance.
The team *also* showed some telemetry data and statistics from some real-life webpages. On some "javscript heavy" pages JavaScript accounts for a good 30% of the total elapsed time (the rest goes to layout, rendering, network, latency etc.). On other sites the JavaScript share was negligible.
That is why it makes sense to focus on performance in other areas as well. The current "mine is bigger than yours" Sunspider competition is missing the point. It doesn't matter if you have a JavaScript engine that is 2x faster than the nearest competitor if you waste an equal amount of CPU on rendering or layout.
I'm working with TFS on a daily basis and I am thoroughly impressed - with the possible exception for the code "merging" tools. I am curious, what "nice, high quality open source solution" would be an alternative? This is not a jab or anything, but using TFS was the first time I realized how much an integrated source control, team collaboration site, project management integrated solution makes sense.
So, is there an open source integrated solution or combo which will meet the following requirements?
For example, the entire ASP.NET API suffers from a similar mismatch of encodings flaw: All of the data binding controls fail to properly HTML encode strings coming from a database.
In fact, ASP.NET has some very sensible options for addressing this issue. Take for example the (infamous) DataGrid. In DataGrid you define columns. The column to "bind" to a datasource (database/collection/etc) is called BoundColumn. It has a property called HtmlEncode. It has a default value of true . Which means that contrary to your claim, if you use this "data binding" control, ASP.NET *will* encode data bound text by *default*
The Literal control is just that. It defaults to displaying literal text. However, it *also* has a property so set whether to pass-through, encode or translate html.
It is true that some controls (like e.g. RadioButtonList) do not support encoding the *text* property. Those controls render in a way where you should never set anything but plain text anyway. If you were binding HTML text to radiobutton lists, checkbox lists or select controls I suggest you take a good long look at the requirement instead.
The one time I wrote an ASP.NET app, I had to spend weeks going through and replacing all of the simple-looking bind statements with explicit calls to a method that would both bind and encode.
Sorry, but that is just stupid. You should simply have set the encode property of the control you were binding to instead. If you were binding to a control which did not expose such a property, maybe you should have used a control which did?
If you've only ever written a single ASP.NET application, perhaps you refrain from making bold faced criticism on a subject where you are obviously not qualified.
Even in the upcoming 4.0 release, the flaw is still there. I suspect that it won't ever get fixed.
No, it will not be fixed, because it is a feature, not a flaw. This is a case of an unexperienced developer misunderstanding the framework and failing to use the correct components. But there's a fix for that, too.
All studies analyzing security vulnerability reports or released patch sets as a measure of OS security simply prove that the researcher is a fucking idiot. It's IMPOSSIBLE to measure security in this way because you are comparing lawn tractors to jet skis.
That is right. It is much better to rely on Apple adds to get the "real picture". Because we all just "know" that OS X is secure by design, that it is immune to viruses and stupid users.
Instead of any form of metric let's just vote who's secure and who's not. Better yet - let's leave it to the blogosphere and biased forums.
Or maybe you should read the IBM report on "the economics of exploits".
Yeah, I've read this "market share" argument used as a defense for shoddy MS code time and time again. That just doesn't cut it.
So you think that an attacker thinks he must exploit each platform proportional to the market share?
Or do you believe that each attacker randomly chooses a platform to specialize in proportional to market share. Or do they keep a list with number of slots according to each OS's market share?
Consider this:
Now, if the targets were 10 ft in front of you and both easily hit, how would you spend your 12 shots? Would you aim 3 shots that the smaller target and 9 shots at the larger target because that seems the fair thing to do? Or would you just shoot all 12 shots at the smaller target and go home with $2400? I know what the typical person would do.
Only when you move both targets so far back that both of them gets pretty hard to hit would any sane person consider spending any rounds on "OS X".
Attackers chose target platform based this simple economics. As long as Windows has 15 - 20 times (worldwide) the market share of OSX and as long as the limiting factor of attacks is time (the actual creation of an exploit), the attackers are going to target Windows each and every time. Only if they cannot find any exploitable vulnerabilities in Windows will they invest in another platform.
Oh, and what about Apache you say? Apache has 2 times the market share of IIS (roughly). Why isn't Apache attacked exclusively for the same reason. The difference here is that these targets are pretty distant; both Apache and IIS are pretty tight. Neither Apache nor IIS5, 6 and 7 has seen successful widespread attacks directly at the server. Neither Linux nor Windows are vulnerable at the network level anymore, especially not when behind a firewall as *all* webservers are nowadays.
The shooters have simply given up (for the time being) and went to another shooting range with better odds. BothApache and IIS has seen widespread attacks against vulnerable applications running on top of the servers. Here you could certainly argue that attackers has a preference for PHP and ASP.Ancient.
Macs have a history of having far less vulnerabilities than Windows.
From IBM research: IBM Internet Security Systems X-Force® 2008 Trend & Risk Report
Look under "most vulnerable operating system". Yes, right at the top, for several years going sits OS X. It actually consistently experiences 3 times the number of vulnerabilities compared to Vista.
You can also do some secunia digging yourself. It shows the same tendency even in the raw data.
OS X may be less exploited but it has far more vulnerabilities. On top of that OS X lacks many of the anti-exploit mechanisms found in both common Linux distros and in Windows Vista.
Vulnerabilities does not have much to do with exploits. A single vulnerability may leads to several independant exploits. Many vulnerabilities will pass unexploited. The difference is incentive. And if pwn2own has showed us anything it certainly confirms this. Macs have consistently been the first to fall, literally within seconds.
To deploy an ASP.NET solution you would need Windows Server 2008 Web edition. List price: $469.
On the other hand, if you know a free way to do it, I'd be interested in hearing it. To my knowledge there is none.
There most certainly is. Just copy the files over to the designated directory on the webserver. It will even detect the changes and gracefully restart the webapp with no service interruption. IIS with ASP.NET installed has everything it needs to compile C# and VB.NET source files, ASP.NET markup etc. It will recognize any assemblies put into the apps /bin folder as well.
If you feel uncomfortable deploying source files and prefer to precompile, .NET comes with a tool called aspnet_compiler. This is a commandline tool and actually builds upon the same code which is invoked during a Visual Studio "deploy".
You don't need Visual Studio at all to develop ASP.NET solutions. You can deploy or compile without it. Not recommended, but entirely possible. This is actually what many big shops do on their build servers.
IIS comes with any version of Windows (server). The cheapest "web" edition of Windows server is listed as $469 and it is perfectly capable of running most corporate websites.
Here's what I wonder when people advocate using all available RAM for running programs: what happens when I try to launch another program ? Parts will have to be swapped out, and again when the new program has a genuine need for more memory.
Some parts will not have to be swapped out. If the memory is not "dirty" it can just be deallocated. This is how Windows has handled dll's for ages: If a loaded dll code block made it to the front of the "standby" list it could just be discarded as loading the memory from the dll file could always be done.
Incidently, Windows Vista improved on this scheme and introduced memory priorities. This way an application - even a user-mode process - can happily consume RAM to improve its performance. If it marks the memory with a low priority and "non-dirty" (because it has a way to reload it in a fail-safe way) it *will* just be discarded when another process needs memory. On top of that, lower priority allocations will never cause higher prioritized memory to be swapped out.
Applications should use the amount of memory they need, preferably leaving caching to the operating system. Applications generally cannot know when other processes need the RAM better, and AFAIK cannot be told to release memory by other applications in any standardized way.
That may be so for most operating systems, but since Vista, Windows apps can assign memory priorities to their allocated memory. This was introduced to counter the after lunch syndrome where a memory intensive process (e.g. a search indexer that springs into action on idle conditions) has evicted all your procceses memory while you were eating. Processes can also register to be notified when their memory is evicted and may choose to just drop the memory instead of having it swapped to disk.
A process such as Windows Defender or the search indexer can now allocate memory with a lower-than-normal priority. This will not cause higher prioritzed memory to be swapped out and this memory will be the first to be evicted when higher-priority memory is allocated.
Windows Superfetch is an example of a user-mode process which leverage this memory infrastructure to allocate memory in a speculative manner. If memory is allocated with a higher priority, Superfetch readily gives up the memory with no additional disk access.
So while most operating systems indeed do not have a standardized way to tell applications to give up memory, this is exactly what Windows Vista, Server 2008 and later feature.
No, the real issue is that Microsoft appears to be slated for a massive success with Windows 7. At this point some Microsoft detractors will leap upon any issue in an attempt to spoil the party. In this category you find Randal C. Kennedy of InfoWorld who leapt on to this issue with blatant disregard for any facts. Even if the original blogger and mr. Kennedy were so stupid as to believe this issue was a memory leak and that it caused the crash, by their own account it would only manifest itself under very specific circumstances:
So, even if this was a bug, only users with
No, this whole bruhaha has a distinct smell of desperation about it. And kdawson is - as usual - all to happy to assist.
MS isn't improving the performance or security of their operating system.
Huh? Windows Vista introduced some really low level:
It is widely recognized (at least among security researchers such as Charlie Miller) that Vista has improved security a great deal:
Windows 7 also has some kernel tweaks which further improves performance and scalability
Intel and AMD have been making dual-core CPUs for more than FOUR YEARS.
What your point? All major operating systems have supported multiple cores FOR YEARS. Even XP had support for 2-4 cores IIRC. The article you linked to was not an announcement that Windows now can use multiple cores, it was an announcement of the new tweaks (removal of spinlock and 256 core scalability) and of the new Concurrency and Coordination Runtime (a.k.a. "concert") - which is user mode threading and is in addition to the traditional kernel mode threading with processes and threads.
Um, wait. Mono is said to be a free as in speech implementation of C#, but aren't the codecs, which are what really matters for watching video, still proprietary? (Not a rhetorical question; I'd really like to know.)
Yes, many of the codecs (all?) aren't even Microsoft property. Rather they are the IP of 3rd party codec developers often incumbered by patents.
Microsoft has licensed these commercial codecs with the right to re-distribute from the MS websites. This allows MS to use them in Silverlight.
Microsoft also entered into an agreement with Novell (and by extension the Mono project) to make the codecs available to Mono users as well. But to avoid violating MS license with the IP holders the Mono users are required to download the codecs from the MS website.
This is nothing sinister. The codecs were never Microsofts to hand over in the first place. The end result is almost the same: Mono/Moonlight users get access to the codecs with only a minor added inconvenience.
Of course, the codecs are still not *free* as in speech. Only the original IP holders can set them free. And it will probably be a cold day in hell before that happens.
Who is this Noone fellow?
Apparently, he is some moron who actually reads the summaries. Go figure.