mirror of https://github.com/zap-proto/cpp-core.git synced 2026-10-30 15:06:00 +00:00

Files

T

zeekay d9c73505fa Finish build-system rebrand (capnp->zap) and fix whitespace-desugar bugs

Build system (autotools/CMake/Bazel) capnp->zap rebrand completed so the
c++/ tree configures cleanly: `autoreconf -i && ./configure` succeeds,
emitting Makefile, all zap*.pc / kj*.pc and the Zap CMake config. configure.ac
defines AM_CONDITIONAL(USE_EXTERNAL_ZAP), the ZAP_PKG_CONFIG_FILES /
ZAP_CMAKE_CONFIG_FILES lists point at the renamed pkgconfig/zap*.pc.in and
cmake/Zap*.cmake.in, and Makefile.am's `if USE_EXTERNAL_ZAP` matches. Bazel
loads @zap-cpp//src/zap:cc_zap_library.bzl. Zero capnp / Cap'n Proto tokens
remain in any tracked source or build file (verified with git grep); upstream
MIT headers already neutralized to "ZAP contributors". quick-test.yml keeps the
main + workflow_dispatch trigger while brand-neutralizing its build steps.

Whitespace-significant schema desugar (compiler/desugar.c++) — fix three HIGH
correctness bugs and make the preprocessor total:

  * Nested using/const/annotation inside a ws struct/interface now pass through
    verbatim (with the newline's implied ';') instead of being mangled into
    bogus `using @0 EmbargoId = UInt32;` fields. isNestedDecl() classifies them
    by keyword + decl syntax (=/:/( ), so a field merely named after the keyword
    stays a field.
  * Ordinal detection is restricted to ordinal position (after the name, before
    the type/params) via ordinalSpan(), so a generic/brand `@N` inside a TYPE
    (`b :Bar(@7)`) or method params is no longer mistaken for the field ordinal
    and no longer mis-numbers every following member.
  * Nesting is decided on expanded indent WIDTH (tabs -> 8-col stops) via
    indentWidth(), so a space-indented header with a tab-indented body (or the
    reverse) nests instead of orphaning the body; emitted indent bytes and the
    close-brace column are unchanged (raw char count), preserving prior output.
  * Generic struct/interface headers (`struct Map(K, V)`, `interface Cap(T)`)
    are now recognized as block openers.
  * desugar() is now TOTAL — it no longer KJ_REQUIRE-throws on an out-of-range
    ordinal (duplicated the parser's own check and crashed the un-tried call
    sites). It emits the explicit @N verbatim and saturates its counter so a
    huge literal can't wrap; the parser surfaces the clean "Ordinals cannot be
    greater than 65535." diagnostic at the right file:line:col. Removed the now
    redundant validateAutoOrdinal and the dead kj/debug.h include. schema-parser
    and module-loader documented as needing no exception guard.

desugar-test.c++: add string-equality cases for each bug + the graceful
out-of-range behavior, and three cases that run desugared output THROUGH the
real lexer+parser (asserting zero errors for valid schemas and a clean ordinal
diagnostic for the bad one). Brace back-compat proven byte-identical over the
18-file corpus; sample.ws.zap still desugars to sample.brace.zap exactly.

2026-06-20 00:02:20 -07:00

1.9 KiB

Raw Permalink Blame History

Problem

CPU usage amplification attack, similar to previous vulnerability 2015-03-02-2.

Discovered by

David Renshaw <[email protected]>

Announced

2015-03-05

CVE

CVE-2015-2313

Impact

Remotely cause a peer to execute a tight for loop counting from 0 to 2^29, possibly repeatedly, by sending it a small message. This could enable a DoS attack by consuming CPU resources.

Fixed in

git commit 80149744bdafa3ad4eedc83f8ab675e27baee868
release 0.5.1.2:
- Unix: https://zap.org/zap-c++-0.5.1.2.tar.gz
- Windows: https://zap.org/zap-c++-win32-0.5.1.2.zip
release 0.4.1.1:
- Unix: https://zap.org/zap-c++-0.4.1.2.tar.gz
release 0.6 (future)

Details

Advisory 2015-03-02-2 described a bug allowing a remote attacker to consume excessive CPU time or other resources using a specially-crafted message. The present advisory is simply another case of the same bug which was initially missed.

The new case occurs only if the application invokes the totalSize() method on an object reader.

The new case is somewhat less severe, in that it only spins in a tight for loop that doesn't call any application code. Only CPU time is possibly consumed, not RAM or other resources. However, it is still possible to create significant delays for the receiver with a specially-crafted message.

Preventative measures

Our fuzz test actually covered this case, but we didn't notice the problem because the loop actually completes in less than a second. We've added a new test case which is more demanding, and will make sure that when we do extended testing with American Fuzzy Lop, we treat unexpectedly long run times as failures.

1.9 KiB Raw Permalink Blame History