做起来很简单，创建一个 dotfiles 目录，把所有要同步的配置文件都放到这个目录下，并重命名去掉文件名开头的点，以免被 Git 忽略。写了一个脚本链接这些配置文件到 HOME 目录：

1
2
3
4
5
6
7
8
9
10
11

#!/usr/bin/env ruby

safe_mode = ARGV.include? '--safe'

files = %w(zshrc tmux.conf gitconfig vimrc emacs gitignore_global LS_COLORS)
files.each do |file|
  unless safe_mode and File.exists?("#{ENV['HOME']}/.#{file}")
    %x(ln -s -i -v $PWD/#{file} ~/.#{file})
    puts ".#{file} linked" if safe_mode
  end
end

为了方便同步脚本到 GitHub，我在 .zshrc 中定义了两个命令用来上传、下载最近的脚本配置：

1
2

alias pull-dotfiles='pushd $HOME/dotfiles && git pull origin master && ./link-files.rb --safe; popd'
alias push-dotfiles='pushd $HOME/dotfiles && git add -A && git commit -m "Update" && git push origin master; popd'

pull-dotfiles 可以获取最新的配置，push-dotfiles 则是提交最近的改动到 Git 服务器。我的配置文件在 https://github.com/zellux/dotfiles，希望对大家有用。

1
2
3
4
5
6
7
8
9

$ curl -I www.heroku.com
HTTP/1.1 200 OK
Server: nginx
Date: Fri, 17 Feb 2012 17:36:44 GMT
Content-Type: text/html; charset=utf-8
Connection: keep-alive
Etag: "f74bb78aa48d36e6a0b2072a131b20b9"
Cache-Control: public, max-age=300
Content-Length: 15481

可以看到响应头中给出了请求内容的 ETag 为 f74…b9。接下来我们再次向服务器发起请求，并通过 If-None-Match 字段告之服务器我们已经获得过一份 ETag 为 f74…b9 的内容。服务器收到请求并生成页面后，如果发现页面的 ETag 不变，就会返回 304，声明缓存有效：

1
2
3
4
5
6
7
8

$ curl -I -H 'If-None-Match: "f74bb78aa48d36e6a0b2072a131b20b9"' www.heroku.com
HTTP/1.1 304 Not Modified
Server: nginx
Date: Fri, 17 Feb 2012 17:37:03 GMT
Connection: keep-alive
Last-Modified: Fri, 17 Feb 2012 17:34:00 GMT
Cache-Control: public, max-age=300
ETag: "f74bb78aa48d36e6a0b2072a131b20b9"

浏览器在访问网页时，记录下上一次服务器返回的 ETag，在下一次访问该网页时发送这个 ETag，这样就能有效的利用本地缓存，减少不必要的网络传输了。

Nginx 和 Apache 都很好的支持了 ETag 功能，它们会为静态资源计算 Hash，并将它作为 ETag 返回给客户端。 而对于 CPU 负载较高的应用，还有一个可以优化的空间。Web 服务器在处理客户端请求时，通常的过程是从数据库读取所需数据，交给模版引擎生成 HTML，计算该页面的 ETag，再回复客户端。事实上所需的数据读取完成后，就足以判断缓存是否有效了。

Rails 早在版本 2.2 就加入了 stale? 方法方便开放人员自定义 ETag。以一个博客文章页面为例，页面内容由文章和评论内容生成，如果这两份内容都没有变化，就可以认为客户端缓存依然有效了：

1
2
3
4
5
6
7
8
9

def show
  @article = Article.find(params[:id])
  @comments = @article.comments.all
  if stale?(:etag => [@article, @comments])
    respond_to do |format|
      # ...
    end
  end
end

除此之外，还可以通过 Last Modified 字段控制缓存有效性，Rails 也同样提供了很方便的支持。但是ETag 方法控制缓存更为精确，而且在服务器时间变化时用 Last Modified 容易出错，因此 ETag 往往是更被推荐的方案。

• 添加本地打印机，类型选择 Generic -> MS Publisher Color Printer
• 在 Visio 中打印，选择新添加的打印机，选中 Print to file，点 Properties -> Advanced
• Document Options -> PostScript Options -> PostScript Output Option 中，选择 Encapsulated PostScript (EPS)
• 保存时别忘了加后缀名 .eps

这样输出的 EPS 文件的边框是整个 A4 页面，需要用 epstool 把它们周围的白边框去掉：

1

epstool --copy --bbox figure.eps figure-fixed.eps

epstool 在常见的几个软件源中应该都能找到。

前期

1. 探路农民不能少，我一般在 14d 的时候拉个农民出去探路。探到对方位置后农民别急着走，要在对方路口停留一会儿，注意对手的第一个枪兵有没有跑出来，以便做好防 rush 的准备。同时这也避免了对方农民在你基地旁造一个欺骗性的地堡时，拉过多的农民下来防守。

2. 分矿处女王造出来后第一件事是铺菌毯而不是补虫卵。第三个女王也一定要出，保证菌毯铺开的速度。

3. 防火车的话，我现在还是倾向于用蟑螂。用蟑螂的另一个好处在于配合小狗应付对手第一波坦克+枪兵的压制比较有效，第一波出来的时候自爆速度往往还没有好，在没有菌毯的地方很难起效果。

4. T 开局还有几个变种，如果看到对方出了火车，数量不多，而且其他地面部队也不多的话，还是老老实实补个 bv 造防空吧。

中期

1. 还是关于侦查。对方二矿开始运作后，小狗要时不时的看看对方家门口。一要注意对手兵力组合，二要注意攻防。如果枪兵不多也没升攻防，对手就有可能用机械化部队了。

2. 如果对手是标准的枪兵+坦克的组合，我倾向于防下对手第一波部队或者自己飞龙出来后再开三矿。不要因为对手开矿早，就以为自己也能随意补农民发展经济了。现在 T 第一波的 timing 都抓得蛮准，三矿农民补早了很有可能第一波就被推掉了。

3. 相反，打机械化组合就要利用对方部队成形前的真空期尽早开矿，这也是前面强调小狗侦查的原因。

4. 开三矿后记得在主矿分矿上都码上几个地堡，这点可以好好像雀茶学学。T 空投你的目的不单单是骚扰经济，而是让自己的主力部队能舒舒服服的推到合适的位置。防下对手一船空投后发现对手已经在咽喉位置架好坦克，摆好枪兵阵形了，这时候就很难打下来。

5. 对方坦克阵慢慢推进的时候切记一定要耐心，对手总能出现疏漏的。同时飞龙记得吃掉落单的补给部队。

6. 小狗+自爆和对方枪兵+坦克打正面的时候，能包最好包，不能包也要记得拉一队小狗拦住枪兵，干扰走位。

7. 怎么打机械化。发现得早的话我一般就做好龙狗换家的准备了，成功率也不低。但是发现晚的话，只能硬着头皮打正面了。现在 GSL 上比较常见是在对手刚出家门，坦克还没架起的时候，用蟑螂吸引火力，同时大量的自爆上去换雷神。我试了几次效果不是很好，可能是时机没选择好的缘故吧。

8. 飞龙一定要保存好。攒多了威慑力非常大，能很有效的牵制对手的部队。

9. 天梯上有时还能看到另一个比较奇葩的战术：爆维京。听起来很不靠谱的战术，但是实战中经常能把人打懵（Z 人口补不上，对方维京成型后地面骚扰能力也很强）。当然这种战术应对起来也不难，多预留点人口，每个分矿都码几个堡，准备一两队小狗，接着出飞龙就好了。类似的战术还有火车女妖流，都是能打得你很不舒服，但是一旦放下来就没啥威力的战术。

后期

1. 我觉得 ZvT 后期的关键在于防空投，因为自爆+狗+感染+母巢王虫的组合基本不怎么怕 T 打正面。但是三攻三防的枪兵拆分矿的能力很强，对应方法，也就只有放好领主侦查，同时在分矿补更多的堡了。

2. 出母巢王虫后记得拉上所有的女王，加血效果会让对手很无语。

其他补充

一个女王加虫卵的技巧。星际2里有一个切换主基地的快捷键，默认是Backspace，我把它设置成了Tab上边那个键。把所有女王编队后，按住Shift，点切换键，按v后再点一个基地，再按切换键，再v一个基地，这样一轮循环下来可以给所有基地注上虫卵。

不过这么做有一个问题就是女王数量比基地数少的时候，会出现女王到处跑的现象。我现在用的方法是不按Shift，点切换键快速切到基地视角，如果这个基地旁有女王就控制它注卵。这样操作上麻烦了一点，而且注卵时间上有个判断的延迟，但是灵活性高了不少。

Why

在 github 上捣鼓了一阵子 octopress 后，决定把原来的 wordpress 博客的数据转移到这个 octopress 博客上了。相对于 wordpress，octopress 的优点在于：

• 支持 Markdown 语法。Markdown 是 github、stackoverflow 上的默认标记语言，写笔记我也一直用这个。Mac 平台上有不少好用的 Markdown 编辑器，例如收费的 Byword，免费的 Mou，这些工具都增加了写日志时的愉悦感。

• 静态。对主页空间没有要求，甚至放到 github pages 上都可以。静态页面如果要加评论，可以考虑 disqus 等第三方 JS 工具。

• 对内嵌代码支持很好。内置了 pygments ，这里有一份支持语言的列表。值得一提的是 octopress 还支持内嵌 Gist。

• 日志文件都在本地，而且是纯文本，管理很方便（可以用 git），也不用担心租用的服务器数据丢失等问题。

• rake new_post; rake gen_deploy 这样写博客很过瘾 :)

How

关于 wordpress 到 octopress 的数据转移，本文结尾的两篇参考文章已经说得很详细了，这里再补充几点：

• 编码：jekyll 的 wordpressdotcom.rb 用了 yaml 库生成博客文章的 meta 信息，碰到中文标题会出现乱码，换用 ya2yaml 后问题解决。

• 博客图片：把原来的 wp-content 目录复制过来，再统一改下路径即可。

• 文章格式：wordpress 导出的文章内容格式比较特殊，不是标准的 HTML，因为它的换行都是有意义的，考虑到这点我就把文章保存成 .markdown 后缀了，效果也不错。Vito 的博客上还介绍了 downmark_it 这个把 HTML 转成 Markdown 的工具。

• 评论：用了 disqus，它还支持导入 wordpress 上过去的评论。

• 代码高亮：之前博客用的是一个基于 JS 的 SyntexHighlighter，octopress 自带了 pygments 作为语法高亮工具，两者高亮标记不一样，需要用 nokogiri 转换下。

• RSS：虽然 octopress 自带了生成 Atom 的插件，但是只能生成一个，而之前博客的 /feed/ 和 /rss.xml 都有人订阅，所以得在 nginx 配置里加了几条重写规则保证这些 URL 都有效。

• 主题：octopress 支持用 SCSS 自定义主题。现在这个用的主题还是默认的，改天再考虑要不要把原来的主题也移植过来。

• 写作：建议在 Rakefile 的 new_post 方法结尾启动 Markdown 编辑器打开新生成的文件，这样就免去手动查找的麻烦了。

这个是修改后的 wordpressdotcom.rb，根据我的博客的情况加了一些特殊情况的处理，有同样需求的朋友可以参考下。

参考：

• jekyll 的 wiki
• Vito 的博客日志

ActiveRecord 对象在数据库中的属性并不是以实体变量的方式保存的，如果要为一个属性设置默认值的话，

1
2
3
4
5

class Item < ActiveRecord::Base
  def category
    @category || 'n/a'
  end
end

这样的实现是不可行的。读取和修改这些属性时应该使用 read_attribute 和 write_attribute：

1
2
3
4
5

class Item < ActiveRecord::Base
  def category
    read_attribute(:category) || 'n/a'
  end
end

Hash 和相等性

ActiveRecord 的 hash 值是根据主键的值计算出来的，这就意味着未保存对象的 hash 值是不可靠的。同样两个 model 对象的相等比较（即==操作符）也是基于主键的，所以两个 model 对象即使它们的其他属性不一样，仍有可能被当作相等。

查找

find_by_attribute 方法后面加个 ! 号，即使用 find_by_attribute!，就能在找不到对象的时候触发一个 RecordNotFound 异常，而不是返回 nil。

find_or_initialize_by 和 find_or_create_by 也是两个好用的方法，它们在找不到对象时分别使用 new 和 create 新建一个，并用查找的属性初始化新建的对象。

手写 SQL

不得不手写 SQL 同时又要防止注入攻击的一个比较简洁的写法是

1

Order.where("name = :name and pay_type = :pay_type", params[:order])

回调函数

出于性能考虑，after_find 和 after_initialize 只能通过函数声明的方式定义，即不能用类似 before_validation :normalize_fields 这样的形式。

参考

• Rails 3 Way
• Agile Web Development with Rails

用 PUT 和 POST 创建对象时的一个区别在于，使用前者时客户端知道被创建对象的 URL（例如 /items/3），而后者则不需要客户端了解（例如 /items/new）。

OPTIONS 用来查看客户端对某个资源有那些可用的操作。

正确的设计应当保证：

• GET 和 HEAD 是安全的，即不会修改任何对象状态。多次调用它们的结果应当和只调用一次甚至不调用一样。
• GET、HEAD、PUT 和 DELETE 方法是幂等（idempotent）的。多次调用它们的结果应当和只调用一次一样。

这两点保证了在一个不可靠的网络中，客户端仍能进行有效的操作。

参考：Restful Web Services

1

render :file => filename, :content_type => 'application/rss'

:layout 指定 layout

:status 指定返回的 HTTP 代码

:location 指定 HTTP 头中的 Location 字段

Rails 生成的 controller 代码中，create.json 方法在生成对象后会将 Location 设置为新生成对象的 json 地址：

1
2
3
4
5
6
7
8
9

respond_to do |format|
  if @item.save
    format.html { redirect_to @item, notice: 'Item was successfully created.' }
    format.json { render json: @item, status: :created, location: @item }
  else
    format.html { render action: "new" }
    format.json { render json: @item.errors, status: :unprocessable_entity }
  end
end

参考：http://guides.rubyonrails.org/layouts_and_rendering.html#using-render

跳过测试的方法很简单，spec 的 describe 方法可以给对应的测试加上标签，例如

1
2
3

describe SalesController, :slow => true do
    # specs
end

接下来只要在 spec/spec_helper.rb 中声明跳过这个标签即可：

1
2
3

RSpec.configure do |config|
  config.filter_run_excluding :slow => true
end

与 filter_run_excluding 相反的是 filter_run，指定会被运行的标签，不包含在这个列表中的测试将被忽略。

参考：http://www.dixis.com/?p=283

1. 将任一非零常数赋值给 result
2. 找到该类中所有需要包含在 hash 中的属性，并根据它们的类型进行计算 c
1. 对于布尔类型，将它们转换为 0/1
2. 对于 byte, char, short, 和 int 类型，将它们转换为 int
3. 对于长整型 long，计算高位和低位的异或结果 (int) (f ^ (f >>> 32))
4. 对于 float 类型，采用它的二进制表示，在 Java 中为 Float.floatToIntBits，Ruby 中我估计用 Float.hash 也可以
5. 对于 double 类型，调用 Double.doubleToIntBits 后再次用前面的方法处理得到的 long 类型
6. 对于数组，利用方法 3 合并计算结果
7. 对于其它的对象，递归调用该对象的 hash 方法
3. 将计算结果合并到 result 变量：result = 37 * result + c
4. 返回 result

另外这个博客的域名已经改成了 blog.yxwang.me，原来的域名 techblog.iamzellux.com 仍然可用，但会重定向到新的域名。

直接用 brew install emacs --cocoa --srgb 似乎会碰到编译错误：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

Finding pointers to doc strings...
Finding pointers to doc strings...done
Dumping under the name emacs
unexec: cannot write section __data
--- List of All Regions ---
   address     size prot maxp
--- List of Regions to be Dumped ---
   address     size prot maxp
--- Header Information ---
Magic = 0xfeedfacf
CPUType = 16777223
CPUSubType = -2147483645
FileType = 0x2
NCmds = 20
SizeOfCmds = 3464
Flags = 0x00200085
Highest address of load commands in input file: 0x5dd000
Lowest offset of all sections in __TEXT segment:   0x22f0
--- List of Load Commands in Input File ---

github issues 上已经有人报告这个问题了，解决方法也很简单，运行 brew edit emacs 打开 emacs 的安装脚本，在 def install 的后面加上两行：

1
2
3
4
5
6
7
8

  def install
    ENV['CFLAGS']='-fno-pie -O2'
    ENV['LDFLAGS']='-fno-pie'
    args = ["--prefix=#{prefix}",
            "--without-dbus",
            "--enable-locallisppath=#{HOMEBREW_PREFIX}/share/emacs/site-lisp",
            "--infodir=#{info}/emacs"]
    # ...

再运行一次 brew install emacs，就能在 /usr/local/Cellar/emacs/23.3 下找到支持全屏模式的 Emacs.app 了。M-x ns-toggle-fullscreen 可以在全屏/非全屏模式之间切换。

Google 了一把找到了 netgrowl 这个好东东，它是一个开源的 Python 模块，实现了 Growl 协议，可以向 Mac 或 Windows 上的 Growl 服务发送通知。使用也非常方便，先用 GrowlRegistrationPacket 函数注册一个应用，接着就可以用 GrowlNotificationPacket 发送通知了：

notify.py

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

#!/usr/bin/python

from netgrowl import *
import sys

title = "Notification from Ubuntu"
desc = ""
if len(sys.argv) > 2:
    title = sys.argv[1]
    desc = sys.argv[2]

addr = ("10.131.251.101", GROWL_UDP_PORT)
s = socket(AF_INET,SOCK_DGRAM)
p = GrowlRegistrationPacket(application="Ubuntu", password="i")
p.addNotification("Ubuntu Notifications", enabled=True)
s.sendto(p.payload(), addr)
p = GrowlNotificationPacket(application="Ubuntu",
    notification="Ubuntu Notifications", title=title,
    description=desc, priority=1,
    sticky=True, password="i")
s.sendto(p.payload(),addr)
s.close()

这里的 addr 是接收方的地址，GrowlRegistrationPacket 和 GrowlNotificationPacket 中需要指定 Growl 远程服务的密码。

然后是一个简化 notify.py 调用的 shell 脚本：

growl.sh

1
2
3
4
5

#!/bin/bash

cmd=$@
$cmd
python ~/bin/notify.py Done "$cmd under $PWD is finished"

把 growl.sh 加入到 PATH 中，之后只要运行 growl.sh make all 就能运行 make all 命令 ，并且在执行完成后向 Growl 客户端发送消息了。如果安装了 BoxCar，还能把这条消息转发到 iPhone / iPad 上。

P.S. Growl for Windows 可以在这里找到。

北卡州立大学的学者们提出了一种防止 return-oriented 攻击的思路，思路很简单，一句话概括，就是去掉代码里所有的 ret 指令！

思路很简单，真正做起来还是很复杂的。x86 中的 ret 指令只有一个字节，即 0xc3。要去掉所有的 0xc3，不仅要修改原来代码中的 ret 指令，还要移除其他指令片段中的 0xc3（例如 movl $0xc3, %rax）。接下来我们来看看 EuroSys 10 上的这篇文章是怎么解决这些问题的。

首先是原来就作为 ret 指令用的 0xc3 代码。注意 return-oriented 之所以成功一大原因就是 ret 指令在返回时不会检查栈上的返回地址是否正确。要保证这一点，需要引入一个间接跳转层。传统的调用过程是调用者把返回地址压入栈上，然后被调用函数返回时从栈上得到返回地址并返回。现在我们加入一个新的跳转表，这张表里记录了所有的返回地址，而且它不在栈上，因此不能被攻击者修改。当调用者调用函数时，把返回地址在表中的序号压入栈上；函数返回时，从栈上读出地址序号，再查表得到实际地址，然后返回。通过引入这样一层额外的地址转换机制，攻击者就不能通过修改栈上返回地址让函数返回到任意地址了。

接下来我们要解决其他指令引入的 0xc3，这里面也分几类情况。首先是由于寄存器分配引起的。例如 movl %rax, %rbx 对应的机器码是 48 89 c3，这边就有个 0xc3。对于这一类代码，只需要在编译器做寄存器分配时把有可能产生 0xc3 的情况排除掉即可。

另一类是代码中直接使用了 0xc3 作为直接数。这种情况需要对代码进行适当的修补，以 cmp $0xc3, %ecx 为例，0xc3 这个直接数可以通过 0xc4 - 1 得到，于是这条指令可以被修改为：

1
2
3

mov $0xc4, %reg
dec %reg
cmp %reg, %ecx

到这里所有包含 0xc3 的代码都已经被修改成具有同等功能的不包含 0xc3 的版本了，也就彻底杜绝了 ret 指令被用来做 return-oriented 攻击的可能。对具体实现细节有兴趣的同学可以读一下这篇论文，作者借助 LLVM 生成了一个没有 0xc3 的 FreeBSD 内核。

如果一个程序没有 0xc3，是不是意味着 return-oriented 攻击也从根本上被阻止了呢？

对于栈溢出漏洞，传统的攻击方式是嵌入攻击代码，然后修改栈上的返回地址，使它指向攻击代码段，从而执行攻击者指定的代码。本科时候上过一门计算机系统基础，其中的某一个lab就要求学生做这么一件事。

现在的安全技术已经能比较好的防范传统的栈溢出攻击了。常见的技术有这么几种：

随机空间，前面提到攻击者需要修改栈上返回地址，使它指向注入的代码起始地址。但如果用户栈的起始地址是随机分布的，甚至每次新建一个栈帧时的地址都有一定程度的随机波动，要获得准确的返回地址就很困难了。这个技术大大增加了代码嵌入攻击的难度，但是却没用从理论上杜绝成功的可能性。攻击者可以使用大量的空指令（nop），并在可以修改的区域重复添加攻击代码，以此增加攻击成功的几率。

W ^ X，把所有的可读可写页标记为不可执行，也就是说攻击者无法添加或修改可执行代码，这样包含了嵌入代码的页面就无法被攻击者调用执行了。Windows 的 DEP、 Linux 的 PaX 都利用了这一项技术。

此外还有一些诸如 StackGuard 等栈保护手段，不过由于它们对性能影响很大，实际中使用并不广泛。

这些手段使得在受保护的进程中利用栈溢出嵌入恶意代码并执行变得几乎不可能，然而这并不意味着栈溢出漏洞没有利用的价值了。聪明的黑客们想到了另外一种自定义程序行为的途径：利用程序或者动态库中原有的代码。这些代码虽然本身是良性的，但适当利用的话，同样可以产生恶意的效果。

最简单的手段就是著名的 return-to-libc 攻击。libc 中有一些函数可以用于执行其他的进程，例如 execve 和 system。这些函数很容易被攻击者利用，只要找到一个栈溢出漏洞，并适当的构造函数调用参数，并使栈上返回地址指向这些函数的起始地址，攻击者就能以这个程序的权限执行任意其他程序了！注意这里所有执行的代码都是合法的，所以前面提到的W^{X技术对此就无能为力了。}

return-to-libc 这种攻击方式也有一个局限，就是需要代码库中有 system 这样符合要求的函数，如果对于内核代码，或是检查调用来源的库，return-to-libc 就不那么给力了。于是另一种理论上更强大、也更难构造的攻击方式浮出水面，也就是标题的 return-oriented 攻击。

关于 return-oriented 攻击，我之前的一篇博文已经介绍过这个概念了，这里再解释一下。

一般程序中都包含着大量的返回指令（ret），它们通常位于一个函数的结尾，或是中途返回的地方。而这些返回指令之前的一两条指令，成为了 return-oriented 攻击指令的来源。攻击者要做的就是把这些零零碎碎的指令拼接起来，拼成一段恶意的代码。这里的难点有两个地方，一是怎么找到符合要求的代码片段，二是找到之后怎么拼接。

先来看第一个问题，可用的代码片段虽然多，但是都是固定的。这就意味着原来的一条指令现在可能需要多条指令执行后得到相同的效果了。举例来说，要把一个寄存器赋值为 4 的话，可能没有现成的直接赋值的代码片段，需要一条赋值为 1 的指令，和三条寄存器加 1 的指令拼凑而成。这样通过拼凑，受限的指令可以完成一些基本的操作，再由这些基本的操作，组成一段有实际意义的攻击代码。这里涉及到不少编译相关的知识，具体细节就不赘述了。

关于第二个问题，因为前面找到的代码片段都是以 ret 指令结尾的，所以只要把栈上的返回地址改成片段1的起始地址，代码片段1执行之后就会通过 ret 指令返回，此时读取的返回地址还是在被攻击的栈上，所以攻击者只要把对应位置的值改成代码片段2的起始地址，就能紧接着执行代码片段2了，如此循环，只要栈够大，就可以把攻击片段跑完。

对于 Linux 内核、glibc 这些庞大的程序来说，ret 指令前面一两条指令组成的代码库非常巨大，基本上可以达到图灵完备的要求了，也就是说，只要栈够大，任何程序都能由这些代码片段表达出来。另外这里为什么强调“一两条指令”呢？当然四五条甚至十几条指令的复用也是可以的，只是这样会大大增加搜索空间，要通过这些可能的代码片段生成一个程序需要太多的时间了。

那么如何防范 return-oriented 攻击呢？之后的博文里，我会介绍一些和它相关的国外研究。

最近在Windows上用VMware Remote Control远登虚拟机调试内核的时候，问题就出来了：可能是这个浏览器插件的bug，有时键盘的Caps Lock会被莫名打开。然后我的这个键盘键位又比较少，不想再让Caps Lock键替换另一个用得更少的按键了，于是想到了软件关闭的方法。

搜了下Stackoverflow找到个很好用的Python库SendKeys，只要两行代码就能在Windows下模拟Caps Lock按键了：

1
2

import SendKeys
SendKeys.SendKeys("{CAPSLOCK}")

另外在Linux要模拟按键，可以直接访问/dev/console：

1
2
3
4
5
6
7
8
9
10
11
12

import fcntl
import os

KDSETLED = 0x4B32

console_fd = os.open('/dev/console', os.O_NOCTTY)

# Turn on caps lock
fcntl.ioctl(console_fd, KDSETLED, 0x04)

# Turn off caps lock
fcntl.ioctl(console_fd, KDSETLED, 0)

原问题地址

1
2
3
4
5
6
7
8
9
10
11
12
13

asm (
    "mov %c[rax](%3), %%rax \n\t"
    "mov %c[rbx](%3), %%rbx \n\t"
    "mov %c[rdx](%3), %%rdx \n\t"
    "mov %c[rsi](%3), %%rsi \n\t"
    "mov %c[rdi](%3), %%rdi \n\t"
      : "=q" (fail)
      : "r"(vcpu->launched), "d"((unsigned long)HOST_RSP),
    "c"(vcpu),
    [rax]"i"(offsetof(struct kvm_vcpu, regs[VCPU_REGS_RAX])),
    [rbx]"i"(offsetof(struct kvm_vcpu, regs[VCPU_REGS_RBX])),
    [rcx]"i"(offsetof(struct kvm_vcpu, regs[VCPU_REGS_RCX]))
      : "cc", "memory" );

stackoverflow上问了下才知道这是gcc的operand substitution语法，%c后面跟上常量名，就能在内联汇编中使用这个常量了。

以这段代码为例，vcpu是struct kvm_vcpu类型，[rax]”i”(offsetof(struct kvm_vcpu, regs[VCPU_REGS_RAX])这句话把vcpu->regs[VCPU_REGS_RAX]相对于vcpu的偏移赋值给了rax这一常量。接下来回到第一行mov %crax, %%eax，%c[rax]等于前面得到的偏移量，加上vcpu并取值后就是vcpu->regs[VCPU_REGS_RAX]中保存的值了，这个指令会把这个值保存在%rax寄存器中，从而完成了vcpu的rax寄存器恢复工作。

1. 安装corkscrew，ArchLinux和Ubuntu的源里就有，也可以从http://www.agroman.net/corkscrew/下载源码编译一个。

2. 修改~/.ssh/config

1
2
3
4
5
6

Host gitproxy
User git
Hostname ssh.github.com
Port 443
ProxyCommand corkscrew proxy.example.com 3128 %h %p
IdentityFile /home/username/.ssh/id_rsa

修改其中的proxy.example.com和3128为代理IP和端口，如果代理需要帐号密码，就在ProxyCommand这一行的最后加上密码文件，内容为用户名:密码。

IdentitiFile的参数是对应于GitHub中帐号的私钥地址。

1. 使用git@gitproxy作为新地址访问GitHub即可，例如要clone git@github.com:foo/bar.git，执行git clone git@gitproxy:foo/bar.git即可。

原文地址：http://www.wetware.co.nz/blog/2010/03/cant-access-github-behind-proxy-or-firewall/

这篇论文提出了一种防范是跨站脚本攻击(XSS)的新的方法，发在IEEE S&P 2009上，作者是UIUC的Mike Ter Louw。

所谓跨站脚本攻击，简单地说就是在网页中注入非法的脚本代码，从而达到攻击的效果。比较著名的例子有当年在MySpace上泛滥的Samy蠕虫，通过特殊的脚本注入手段，每一位访问Samy主页的用户，他们的主页都会被修改加上一段Samy is my hero文字，并且他们的主页也会被植入攻击代码，从而把这段脚本扩散给更多的用户。

通常防范跨站脚本攻击的方式有两种。一种做在服务器端，为每一段用户上传的内容做检查，并剔除恶意代码。但这种方式很难保证能过滤掉所有的恶意字符串，一方面攻击方法防不甚防，有兴趣的朋友可以参考下XSS Cheat Sheet，上面给出了很多一般人很难想到的攻击代码的组合方式。另一方面由于现在大多数论坛和博客都支持一些基本的文本修饰标签，所以简单的标签剔除或者重新编码都不可行。

另一种方法是做在浏览器端，但是由于浏览器无法区分某一段脚本到底是来源于不可信的用户还是可信的站点，所以这种方法实现起来也有很大的困难。

这里实现防范措施的一个难点在于，Web应用把生成HTML的返回给浏览器后，就不参与浏览器的HTML解析工作了。这样浏览器就不知道哪部分出现脚本是安全的，哪部分出现是不安全的。

BluePrint就着眼于这个点，提出了一种让Web应用“参与”HTML解析工作的设计。下面通过论文里面的一个例子，简单介绍下它的防范机制。

假如一位恶意的用户在一个博客上上传了这样一段含有恶意代码的留言：

1
2
3
4
5
6
7
8
9
10

<p>
Here is a page you might find
<b """><script>doEvil(. . .)</script>">very</b>
interesting:
<a href=" &#14; javasc&#x0A;ript:doEvil(. . .);">
Link</a>
</p><p style="nop:expres/*xss*/sion(doEvil(. . .))">
Respectfully,
Eve
</p>

可以看到，这段代码里包含了很多可能引发脚本执行的代码，而要在服务器端把这些所有隐藏的攻击可能找出来是一件比较困难的事。那么BluePrint是怎么在不知道这段代码是否含有恶意代码的前提下处理的呢？

首先，这种由用户上传的不可信的字符串会先在服务器端被解析成一棵树，就像HTML在浏览器中被解析一样，这棵HTML解析树可以用一些简单的DOM API来生成，例如appendChild, createElement等。这些描述如何生成HTML解析树的方法会和数据值（URL、标签属性等）一起，通过特殊的编码（Base64）传递给浏览器。例如上面这段代码，最后在浏览器接收到的HTML中，会变成这样：

1
2
3
4
5
6
7

<code style="display:none;" id="__bp1">
=Enk/sCkhlcmUgaXMgYSBwYWdlIHlvdSBta...
=SkKICAgICI+dmVyeQ===C/k/QIGhlbHBmd...
=ECg===C/Enk/gCiAgUmVzcGVjdGZ1bGx5L...
</code><script id="__bp1s">
__bp__.cxPCData("__bp1", "__bp1s");
</script>

在浏览器端，这段特殊的代码会被JS库解析成自定义的命令和数据格式，并由前面提到的DOM API动态生成这些HTML结点，从而达到和传统的方式一样的显示效果。当然可信的HTML代码，例如文章正文，还是按传统的方式传输的。

通过这种方式，BluePrint绕过了浏览器对不可信代码的解析，从而防止了不可信代码里内嵌的脚本的执行。

此外还有一些细节的问题，例如为什么使用Base64编码来描述自定义的命令和数据，而不是常用的例如UTF-8呢？这是因为使用UTF-8的话攻击者就有可能通过构造一段特殊的字符串，而这段字符串对应的编码恰好能起到攻击作用。而使用Base64编码就不会有这个问题。

攻击例子中的第5行和第7行还分别包括了通过恶意URL和CSS风格实现的代码，前面提到的措施还不足以防范这两种类型的攻击。论文里面也提到了相应的解决方案，这里不再赘述，有兴趣的朋友可以搜索论文阅读相关部分。

把BluePrint整合到现有的应用程序里也不难，只要把包含不可信内容显示部分的代码重新加一层包装就行了，像这样：

1
2
3
4
5
6
7
8
9
10

// Code for trusted blog content
// appears untransformed aboveˆˆ.
<?php foreach ($comments as $comment): ?>
    <li>
        <?php
$model = Blueprint::cxPCData($comment);
echo($model);
        ?>
    </li>
<?php endforeach; ?>

在BluePrint的开销方面，包含25个用户评论的wordpress页面产生速度慢了55%，不过作者提到wordpress本身还有HTML解析和恶意代码检查过滤的功能，用了BluePrint后就不需要这些冗余的检查了，所以把这部分代码去掉会快不少。另外由于不可信内容都需要动态的被解码并创建相应的HTML结点，浏览器端的显示速度慢了很多，作者也解释到这种解析开销其实并不重要，因为通常看一篇博文的时候都是先看内容，由于文章内容本身是可信的，所以会以传统的方式传输并显示，若干秒后再显示评论也未必会对用户体验造成太大的影响。

这篇论文给我的感觉是思路很清晰，抓住了主要的难点后用了对应的方法绕过了浏览器的HTML解析。不过应用面上还有一些局限，只能防止不可信代码中脚本的执行，对于需要执行脚本的情形（例如Blogger上的Gadget）就不适用了。MIT去年发在EuroSys ‘09上的BFlow就是针对这样一种情形，通过类似于Flume的标签系统，使得不可信的脚本读取了隐私数据后就无法将它们传输给不可信的网站。

用beamer做了slides，在这里可以下载到: http://zellux-notes.googlecode.com/hg/slides/blueprint/

在superuser上看到一个解决方法，指定历史文件的读写方式为追加，并在每次命令行提示符显示的时候，自动更新bash的历史命令记录。要实现这个方法很简单，只要在.bashrc中加入下面两行代码即可

1
2

shopt -s histappend
export PROMPT_COMMAND="history -a; history -n"

另外如果之前设置过PROMPT_COMMAND的话，只要在history -a前加入$PROMPT_COMMAND; 就行了。

重现这个bug很简单：

1
2
3
4
5
6
7
8
9
10
11

Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> len(sys.modules)
35
>>> foo
Traceback (most recent call last):
  File "", line 1, in
NameError: name 'foo' is not defined
>>> len(sys.modules)
225
>>>

在执行foo之前，当前导入的包只有35个，执行之后却有了225个。问题出在Ubuntu的Apport系统，它为Python添加了一个异常处理方法，这里面的bug导致了这些多余的包被导入。

这个bug已经被人提交并被确认，目前暂时还没有补丁，最简单的避免方法就是把python-apport包卸载 :-)

原文地址： http://rhodesmill.org/brandon/2010/ubuntu-exception-190-modules/