关于假设---看不见的基石

关于假设---看不见的基石（invisible foundation stone）

1序

我们现在的大多数基础理论都是建立在一些简单而明显的假设之上的。

例如在数学领域，在物理学领域，在化学领域

同时也有一些基础理论因为假设的错误或者不够准确，而被新的理论所代替，或者被扩展和修改。

例如“第五公设问题”？

2展开

在漏洞研究中，我们发现：程序的编写和运行都基于一定的假设，如果这些假设与实际状况不匹配，就

会出现错误或纰漏；如果这些假设是安全相关的，那么一旦不匹配就会出现漏洞。

eg.

void chartoint(char *p)

{

     int i = atoi(p);

}

void chartoint(char *p)

{

     if(!p) return;

     int i = atoi(p);

}

如果 *p="1234"; 该程序段正常运行

如果 *p="egxr"; 还能正常运行吗？

也就是：程序员在编写程序时，想当然的认为传进的参数应该是“1234”样式的，然而如果参数样式

不是这样哪？例如，字符串超长，或者字符串为字母串。

3思考

1在实际应用中，这些假设都是不可见的，如何将这些假设可见？

2如何利用这些假设来维系程序的安全性或者验证程序的安全性？

3如何验证假设与实际状况的不匹配？

可以做的工作：

1将假设分类

第一种假设涉及到由编程语言和操作系统提供的基元在执行时的正确性；

第二种假设难以用表示，但是在运行时可以评估。这种假设无法判断，几乎没有一个算法将

环境实例作为输入参数，以检验是否在整个运行期间假设保持不变，因为这种假设太主观了；

第三种假设是可以用决定算法表示的，此时的环境对象是编程语言可用的数据类型。

[from krsul]

还可以分为两类，一类程序语言可表示的，可以用程序来验证假设是否一直保持；

另一类是，程序语言无法表示，但是编译器和解释器可以做到。

2对假设的描述，可以用类C语言

 4延伸

是否可以由这种思想出发，做程序安全性验证？

这种假设的思想，其实是在外部考虑的，程序的（全局）系统环境，程序的（局部）配置环境，程序

的输入环境，还有程序的逻辑环境

这样就对应着一系列假设，某个程序应该在什么样的系统环境、什么样的配置环境、什么样的输入

环境以及什么样的逻辑环境下工作？

其实这些假设是程序员或者架构师默认的（default），并没有具体的体现，当然一些资深的程序员或者

架构师会考虑假设的问题，在某些地方会做验证或者检测，但是这种工作很不全面，或者是没有完全

将其作为一个很突出的问题来考虑。