一个typo,估计是MS的程序员看程序的时候打扫了下键盘，多变了一个&出来 ,导致了一个严重的安全问题。
不过这样的代码应该自己简单测试下就可以测试出来的，难道这块代码没怎么做测试就放了出来？！


ReadFromStream(LPSTREAM ppvData)
{
        SafeArrayCreate(xx,x, user_controlled_len);
        SafeArrayAccessData(xx,& ppvData);
        ReadFile(x,& ppvDat

机会难得，有兴趣的朋友同样把中英文简历发到 alert7 at gmail.com . 标明应聘的是技术产品经理。

Technical product manager job description

Description of Function and Responsibilities: The technical product manager will be responsible for technical marketing documentation and presentations for McAfee’s network security products. We are looking for a highly motivated professional with a proven track record of successfully driving and marketing products in the network security

机会难得，假如有兴趣的话，可以把中英文简历发邮件到 alert7 at gmail.com 。

Web security, P2P/IM Security Researcher

Description:

说到core dump file,想到我在2005年问过的一个问题。

solaris上一个只能执行的文件，可以获得它的文件内容是否为漏洞？

http://www.derkeiler.com/Mailing-Lists/Full-Disclosure/2005-09/0386.html

也是通过core dumpfile手段获得的文件的内容。

那时候的linux就已经没有solaris上的这个问题了。就安全性来讲，我认为linux比solaris安全的多，不管是kernel 还是libc. 以前焦点论坛上还红红火火讨论过setuid shell的安全问题，对比来讲还是linux走在了前面。

用的人多了，该暴露的安全问

既然看了udev那个漏洞，也来说说这个Linux kernel <2.6.29 exit_notify() exploit.

http://www.milw0rm.com/exploits/8478

1: /proc/sys/fs/suid_dumpable 必须是1 or 2（默认好象不开啊）
2: 假如第一个条件满足的话，这倒是个好漏洞，作者也说让人联想到以前那个
prctl(PR_SET_DUMPABLE,2)漏洞，利用方法一致。
3： 这个exploit需要等24小时，其实不需要，改一点就可以缩短到一个小时。而且core文件形式在有些系统上core.xxxx ,自己修改吧。

不是linux kernel的漏洞， 是个非常好用的应用程序漏洞。
http://www.milw0rm.com/exploits/8478

udevd进程处理用户数据不当导致的任意执行命令漏洞。其实邪恶的环境变量不单单是LD_PRELOAD。

int udev_event_execute_run(struct udev_event *event)
{
    struct udev_list_entry *list_entry;
    int err = 0;

    dbg(event->udev, "executing run list\n");
    udev_list_entry_foreach(list_entr

http://www.infiltrated.net/amishAttacks.html

通过逆向VCIM搞定的？

安全无处不在啊，很多应用程序设计的时候就没有多考虑安全问题，认为是私有协议或者是私有接口就不会有安全问题。这点认识显然是有问题的。大大错误估计了那些搞反向工程人的能力，不管是软硬件。
往往那些私有协议和接口的东西是最不安全的。

最近的IC卡遭破解事情也闹的比较热，估计以后还会有类试的事件出来。

例如CVE-2009-0520,例如...,例如....

而且往往这种漏洞是可以稳定利用的。

下面这个是老的。
http://insecureweb.com/%20/newish-web-based-pdf-attack-in-the-wild-with-real-exploit-code/

新的pdf 0day 在这里
http://vrt-sourcefire.blogspot.com/2009/02/have-nice-weekend-pdf-love.html

Maybe you read Michael Howard's twitter feed. If so, you may be wondering why you were asked to turn off Javascript in Adobe Acrobat Reader. Well, I'm here to tell you that if you were to load a PDF file with an embedded

备查
ref http://www.unixwiz.net/techtips/x86-jumps.html

Instruction	Description	signed-ness	Flags	short jump opcodes	near jump opcodes

经常在代码中看到如下比较，eax为HDC类型
and     eax, 7F0000h
cmp     eax, 210000h
jnz       xxxxx;error.
...

我是这样创建这个HDC的。
HDC hDC = GetDC(hWnd);
但不能绕过如上代码的检测。

检查hDC & 0X7F0000是否等于0X210000欲意何为啊？
0X210000是一个怎样一个HDC?
如何才能创建绕过上面这个检测的HDC?

由于个人对windows不是很熟，故blog下，欢迎朋友指点。

Q : GetMetaFile()正常的wmf文件为什么总返回NULL?
A : a7个人认为是WINDOWS GDI32.DLL实现上的一个小BUG.
没有能正确处理wmf最开始WMFSPECIAL结构的情况。
gdi32.dll默认一开始就是一个WMFHEAD.并且由IsValidMetaHeader16来校验其合法性。
解决办法是假如wmf文件以 D7 CD C6 9A 开始，那么直接删掉这 22 个字节的WMFSPECIAL结构。
问题就可以得到解决。

这次为焦点峰会准备了议题。
原来议题题目是《使用虚拟机技术进行数据流分析--分析已知漏洞和发现潜在漏洞》,现在修改为

A 0day exploit for the latest Quicktime7.5.5/Itunes8.0 was released yesterday. The exploit author announced this as a Remote Heap Overflow so we decided to take a look and analyze it.

刚才在群 killer问到有没有人认识 xdxf.cn 和huaidan.org 的人。 出于好奇，我也去看了下，里面有篇 blog GDI+来了 .


正好有个朋友有样本，就分析了简单分析了。 确认是MS04-028，不是最新的GDI+漏洞，也不是杀毒软件误报。


offset 0x39的地方是 szSection等于 1, MS04-028这个