有关 Telegram Desktop (tdesktop) 的远程代码执行（RCE）漏洞，已经有人分析过了，但分析仅仅建构于对 HTTP Bot API 的试验之上，其实说得不太全面，这里补充一下。

TL;DR: HTTP Bot API 是建构于 tdlib 之上的，是对 Telegram 服务端的 API （MTProto API） 的非常高层次的封装。我想知道盲目轻信 Content-Type 标头的 MIME 这一漏洞是直接出现在服务端，还是先出现在 HTTP Bot API、tdlib，然后再传递到服务端的。通过分析前两者的源代码，我认为是直接出现在服务端的。与此同时，直接经由 MTProto API 上传文件是可以手动指定 MIME 的，这可能是另一种漏洞利用的方式，同时也意味着后一种利用链条可能只是未被发掘。然而我认为客户端在这个漏洞里的责任更大。

HTTP Bot API 并不是 Telegram 服务端最终暴露的 API，后者是 MTProto API。HTTP Bot API 只有机器人（bot）可使用，普通用户不能使用；而 MTProto API 既可以被 bot 使用，也可以被普通用户使用。前者开放源代码，任何人均可自行搭建。后者则只有 schema 提供。

进一步地，HTTP Bot API 其实是对 tdlib 的一个 HTTP 封装，同时提供许多便利方法；而 tdlib 又是对 MTProto API 的一个保姆级封装，覆盖了建构一个客户端所需的方方面面。被引用的这条分析里涉及的就是前面说的「便利方法」sendVideo。其关键在于对 Client::get_input_file 这个方法的调用。注解如下：

td::Status Client::process_send_video_query(PromisedQueryPtr &query) {
  auto video = get_input_file(query.get(), "video");
  // 略
}

td_api::object_ptr<td_api::InputFile> Client::get_input_file(const Query *query, td::Slice field_name,
                                                             bool force_file) const {
  // 重载。query->arg(field_name) 实际上获取了请求参数 video 的值
  return get_input_file(query, field_name, query->arg(field_name), force_file);
}

td_api::object_ptr<td_api::InputFile> Client::get_input_file(const Query *query, td::Slice field_name,
                                                             td::Slice file_id, bool force_file) const {
  // 由于重载，通过 file_id 传入了请求参数 video 的值。
  // video 的取值可参见 https://core.telegram.org/bots/api#sending-files
  if (!file_id.empty()) {
    // 本地模式，私有部署可用
    if (parameters_->local_mode_) {
      // 本地文件
      td::Slice file_protocol{"file:/"};
      if (td::begins_with(file_id, file_protocol)) {
        return make_object<td_api::inputFileLocal>(get_local_file_path(file_id.substr(file_protocol.size())));
      }
    }
    // bot 上传的文件
    td::Slice attach_protocol{"attach://"};
    if (td::begins_with(file_id, attach_protocol)) {
      field_name = file_id.substr(attach_protocol.size());
    // 传入了 URL 或 file_id
    } else {
      // force_file 表示强制将多媒体文件作为普通文件发送，sendVideo 一定导致传递 false，从而条件为真
      if (!force_file) {
        // 取得 URL 或 file_id，以后将会传递给 tdlib，最终传递给服务端
        // 如果是 URL，由服务端自行下载 URL；如果是 file_id，服务端查询对应于 file_id 的服务端文件
        // 引用的分析（sendVideo 传入远程 URL）会是这种情况
        return make_object<td_api::inputFileRemote>(file_id.str());
      }
    }
  }
  // 执行到这里意味着这是 bot 上传的文件，或者 bot 传入了 force_file=true
  auto file = query->file(field_name);
  if (file != nullptr) {
    // 取得本地的临时文件名，以后将会传递给 tdlib，最终上传到服务端
    return make_object<td_api::inputFileLocal>(file->temp_file_name);
  }
  return nullptr;
}

经过一段复杂的调用链（从略）后，进入了 tdlib 内部。随后关键调用链如下：MessagesManager::send_message -> MessagesManager::do_send_message -> get_input_media_impl -> VideosManager::get_input_media。最后一步构造了一个 inputMediaDocumentExternal 实例，它最终将经由 MTProto API 传递给服务端。

tl_object_ptr<telegram_api::InputMedia> VideosManager::get_input_media(/* 略 */) const {
  // 略
  if (file_view.has_url()) {
    // 略
    return make_tl_object<telegram_api::inputMediaDocumentExternal>(flags, false /*ignored*/, file_view.url(), ttl);
  }
  // 略
}

该类型专门用于指示 Telegram 服务端从互联网上的 URL 下载文件。因此引用的分析中展示的漏洞如果真实存在的话，那么应当是服务端自己盲目轻信了 Content-Type 标头导致的漏洞，而不是产生了形如「服务端 -> tdlib -> HTTP Bot API -> Content-Type 标头」这样的盲目轻信链。

然而，如果使用 MTProto API，则直接上传的文件其实也是可以手动指定 MIME 的。MTProto API 将文件上传划分为两个阶段：上传、提供文件属性，分别对应 InputFile 和 inputMediaUploadedDocument 。后者有一个赫然的 mime_type 字段。在该字段提供不匹配的 MIME 理论上也是一条漏洞利用的路径，同时也意味着上述的「盲目轻信链」有可能存在于别处。

不过，服务端对文件的元数据其实表现出很矛盾的处理方式，在我过往的试验中，即使该等文件是通过传递 URL 令服务端到互联网上拉取的，它仍会解析文件以确定分辨率、时长等元数据并返回给客户端。如果客户端上传文件，随意指定的元数据也会被服务端检测到并修正，这点在 tdlib 的源代码中也有所体现。不过，服务端的检测能力并不完美，即使是常见如 .mov 容器，它也常常失能于属性检测而依赖客户端提供正确的属性（是的，大部分客户端也会在上传文件时解析元数据并传送给服务端），否则转为普通文件。无论如何，其实 Telegram 服务端对媒体文件还是有着更多离谱的服务端限制的，我已经踩过很多坑了，因此这个漏洞在这个背景下就显得比较低级错误了。不过我认为更大程度上应该归咎于客户端：客户端自己也盲目轻信了服务端，没有做到时刻谨慎行事。

Disclaimer: 我没有进行实际调试以验证被引用的分析和我的猜想各自的正确性，也没有对 inputMediaUploadedDocument 是否任意接受 mime_type 进行试验。上述结论是基于粗略的代码审计及我长久以来使用 MTProto API 的经验（尤其是我在业余项目 RSS-to-Telegram-Bot 中大量使用 inputMedia*External 的经验）得出的，未必完全正确。读者如果进行了试验，可以在评论区留言，我会跟进更新。