对于所有类型环境中的开发人员来说，安全性正成为一个越来越重要的主题，即便过去一直认为安全性不成问题的嵌入式系统也是如此。本文将介绍几种类型的编码漏洞，指出漏洞是什么、如何降低代码被攻击的风险、如何更好地找出代码中的此类缺陷。
注入攻击
通过将信息注入正在运行的流程，攻击者可以危害进程的运行状态，以反射到开发人员无法保护的某种最终目标。例如，攻击者可能会通过堆栈溢出（stack corruption）将代码注入进程，从而执行攻击者选定的代码。此外，攻击者也可能尝试将数据注入数据库，供将来使用；或将未受保护的字符串注入数据库查询，获取比开发人员更多的信息。无论出于怎样的目的，注入总是一件坏事，总是需要谨慎对待的。
最恶劣的注入攻击形式也许是代码注入——将新代码置入正在运行的进程的内存空间，随后指示正在运行的进程执行这些代码。此类攻击如果成功，则几乎可以进行任何操作，因为正在运行的进程完全被劫持，可执行攻击者希望执行的任何代码。
此类攻击最著名的示例之一就是 Windows 动画光标攻击，这正是本文要讨论的模式。攻击者利用一个简单的 Web 页面将形式不当的动画光标文件下载到查看者的 PC 中，导致浏览器调用此动画光标，动画光标调用时可能发生任意代码的注入。实际上，这是一个完美的攻击载体：因为它不要求对被攻击机器的任何实际访问、最终用户根本意识不到任何可能发生的麻烦；此外，如果攻击效果的恶意也是适度的，则对最终用户的外部影响几乎是零。
考虑示例 1(a)，当然，这改写自 Windows 攻击，它构成了此类攻击载体的基础。这里的开发人员对于传入流的可靠性做出了基本的假设。信任流和并相信一切都没问题。使用基于堆栈的将被非串形化(deserialized)的类型调用函数，未知数据流和代码注入肯定会在某个时间点出现。
(a)
void LoadTypeFromStream(unsigned char* stream, SOMETYPE* typtr)
{
int len;
// Get the size of our type's serialized form
memcpy(&len, stream, sizeof(int));
// De-serialize the type
memcpy(typtr, stream + sizeof(int), len);
}
(b)
void foo(unsigned char* stream)
{
SOMETYPE ty;
LoadTypeFromStream(stream, &ty);
}
(c)
void LoadTypeFromStream
(unsigned char* stream, SOMETYPE* typtr)
{
int len;
// Get the size of our type's serialized form
memcpy(&len, stream, sizeof(int));
// GUARD
if( len < 0 || len > sizeof(SOMETYPE) )
throw TaintedDataException();
// De-serialize the type
memcpy(typtr, stream + sizeof(int), len);
}
示例1 注入攻击。
这是怎样发生的？假设您调用示例 1（b）中的函数。我们就得到了一个易于利用的攻击载体。这里的问题在于 SOMETYPE 在编译时的大小是固定的。假设此类型在内存中使用 128 个字节表示。再假设您构建传入流时，使前 4 个字节（要非串形化的内容的长度）的读数为 256。现在，您没有检查正在处理的内容的有效性，而是将 256 个字节复制到了仅为 128 个字节的保留堆栈空间内。
考虑到发布模式堆栈的典型布局，您显然遇到了麻烦。查看堆栈，了解原因所在。每个被调用的函数都会将其本地数据布设到堆栈的一个帧内，通常是通过在输入时从堆栈指针减去本地数据的已知大小（加上处理调用链本身所需的任何管理数据）实现的。编译器发出的理想函数 prolog（伪代码）如下所示：
.foo
sub sp, 128 ; sizeof SOMETYPE
随后，对可利用函数的调用应如下所示：
push sp ; push the SOMETYPE
local variable
push ap ; push the stream
pointer (comes from 1st argument)
call LoadTypeFromStream
ret