March 2009 Archives

First of all, thanks goes to all people who has helped me on this project, especially Pav (portmgr@) who gave it a twist on pointyhat.

It seems that this has taken me almost a month and 20 commits to get into the tree, after the code is ready. At the beginning, the changeset was ~200KB, and I believe it's not good to just go ahead and commit it in one time, since it makes reviewing hard. Instead, I manually split it into smaller, functional related chunks, and commit it part-by-part.

The overhauled libc Berkeley DB code consists several enhancements. First, almost all Berkeley DB 1.86 improvements has been merged, except their new hash routines which would introduce an unavoidable file format change which apparently does not make it a good candidate for FreeBSD libc.

There is a changeset that has changed mpool(3) interface. I doubt if any application would make use of it but I provided a compatibility shim anyway.

Also, this changeset brings some security measurements that would reduce the risk of potential information leak. When allocating data, the libc now requests zero'ed memory, and zero's buffer memory upon free(). While I believe it's the client program's responsibility to zero out any sensitive information, it looks like that this makes it harder to dump sensitive data "by accident". Speaking of a reported security problem about postfix, it seems that the zero-before-free is more useful to mitigate the situation.

This overhaul also brought several memory leak fixes and crash fixes.

最近帮公司的一个客户做了一个数据库迁移,客户声称数据是 utf-8 的,然而在使用过程中出现了许多乱码,检查发现数据并非 utf-8,而是 utf-8 编码之后的 big5,而排序方式更是混乱不堪的默认的utf8-swedian-ci。

MySQL的国际化支持很差。MySQL从 4.1 版本开始大刀阔斧地进行了不兼容的改动,简单地说,这些改动让相当多的操作默认以UTF-8进行,然而这会给旧的应用程序带来很多问题。许多文献推荐使用 SET CHARACTER SET 作为 workaround,尽管这能够解决一些问题,但这种做法本质上会导致 MySQL 进行额外的转换,因此并不是十分理想。

正确的方法是把所有的东西都转换成 UTF-8。一个比较常见的错误是使用SET NAMES UTF8并直接从原始的 Big5 表中导出。这种情况下,文字会被以UTF-8编码的big5方式保存。比较简单的做法是将其直接导入数据表,并以 latin-1 导出:

mysqldump -u 用户名 -p密码 --skip-extended-insert --default-character-set=latin1 --databases 数据库名 > big5.sql

接着,使用 piconv (随 Perl 提供)来转换编码。我个人认为这个工具比 uconv 和 iconv 都要好。

piconv -f big5 -t utf8 < big5.sql > utf8.sql

接下来要把 utf8.sql 中的 latin1 等不正确的编码改为 utf8(通常,简单地sed即可)

最后重新导入。前面 skip-extended-insert 可以让发生错误时显示较具体的行号,这对于较大的数据库而言会比较方便。

声明:此 HOWTO 文档以现状方式提供,不提供任何担保。此文档为个人作弊条,本人会对部分疑问进行解释,但同样不提供任何保证。

此篇按下述授权发表:

/*-
* Copyright (c) 2009 Xin LI <delphij@FreeBSD.org>
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
*    notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
*    notice, this list of conditions and the following disclaimer in the
*    documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
*/

终于,是吧,直接写入BIOS的终极木马诞生了。十几年前的CIH病毒等等现在看来都是小儿科。

这种东西迟早会出现,这个我并不觉得奇怪,但是这次CORE实现的这个攻击是一个通用性很强的攻击,换言之,它能够适应多种不同品牌的 BIOS;实际上我认为这种攻击很可能也适用于网卡、RAID卡、显卡上面的可刷写ROM。例如,如果在 VBE 中写上这么一个玩意呢?现在看来 ACPICA 真是一个有前瞻性的玩意,也许 Intel 早就意识到了这种问题可能会发生?

不管怎么说,我想这是一次很好的机会来让用户知道:永远不要获得不应该获得的权限,如果你是小白,就不要用管理员身份登录!这件事真的很危险。

Google SoC 2009/FreeBSD

| 3 Comments | No TrackBacks

之前在水木社区发过,这里也发一下。

我们目前正在寻找有意参加这次活动的在校学生。Google Summer of Code 是由Google公司赞助的供在校学生参与开源项目的暑期活动。目前,FreeBSD已经被选为符合资格的 mentoring organization,这是 FreeBSD 第 5 年参与 GSoC。

重要的日期:

  • 3月23日 - 开始接受申请
  • 4月 3日 - 申请截止日期
  • 4月15日 - 对申请的审核结束
  • 4月20日 - 正式宣布赞助的学生 (http://socghop.appspot.com/
  • 5月23日 - 项目正式开始
  • 7月 6日 - 开始提交中期评估
  • 7月13日 - 中期评估最后日期
  • 8月10日 - 推荐的项目完成时间,接下来的一周时间建议用于修正代码、完善文档等。
  • 8月17日 - 开始提交最终评估
  • 8月24日 - 最终评估deadline

Google将为获得资助的学生提供每人 $4,500 的资助,分3次支付;同时,对于每个项目,Google还会为对应的开源项目提供 $500 的资助。

关于 FreeBSD 本次 SoC 活动的 网站

关于本地特权提升

| 2 Comments | No TrackBacks

FreeBSD 今天发布了 2009 年第 6 号安全公告 FreeBSD-SA-09:06.ktimer。这个安全公告适用于 7.0-RELEASE 以上到修正日期之前的所有 FreeBSD 版本。

由于这个安全公告修正的是一个零时差 (0-day,也就是发现者直接对问题进行了全面披露,而不是等待供应商修正之后再发布漏洞细节) 披露的漏洞,因此,适当地评估其风险并采取措施就非常重要。安全公告中提到,这是一个"Local privilege escalation"(本地特权提升问题),这种问题属于一类非常常见的(特别是 Linux 内核)、严重的安全漏洞,具体来说,通过一定的方法,登录在系统上的用户可以提升其权限,并实施进一步的攻击。

关于这类漏洞的一个常见的误解是,"本地"漏洞通常是没什么大碍的。然而,那种无关大碍的一类"本地"漏洞,指的是只能在本地控制台触发的问题。例如,如果手中有一张包含了某些工具的Windows PE光盘,用它启动系统便可以得到本地的管理员权限----这是一个安全问题,但是并不严重,因为事实上如果别人能够接触本地系统,那么他就可以做任何事情。

而 FreeBSD-SA-09:06 指出的问题则不是这类问题。在其上下文中,"本地"是指能够登入系统的任何用户,以及能够以本地用户身份运行的服务进程。对于 Web 服务器而言,这是一个非常严重的安全威胁----例如,如果在设计时因为疏忽而没有考虑上传文件是否有可能由于某种条件被执行,那么,之前这可能只是一个简单的 DoS 问题(例如,用户可以上传一个不停 fork() 的程序,将 www 用户的进程配额耗尽而导致新的服务请求无法被及时响应),而有了这个漏洞,这些问题便成了远程特权提升问题,其危害也就非常严重了。

今天路过Castro的时候看到了El Camino Real上那家Washing Mutual上面原先大字的WASHINGTON MUTUAL换成了CHASE的logo,隐约还能看到WAMU大字留下的痕迹。这家百年老店就这样一点一点地消失了。

夏令时来了

| 3 Comments | No TrackBacks

出来混迟早要还的。

PST 01:59:59AM之后,系统立即将时间改成了PDT 03:00:00AM。时间就这样在不知不觉中少了一个小时。

Monthly Archives

Pages

OpenID accepted here Learn more about OpenID
Powered by Movable Type 5.2.3