Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bro 2.6.2 #1525

Closed
dougburks opened this issue May 30, 2019 · 3 comments

Comments

Projects
1 participant
@dougburks
Copy link
Contributor

commented May 30, 2019

No description provided.

@dougburks dougburks self-assigned this May 30, 2019

@dougburks dougburks added this to To do in 16.04.6.2 via automation May 30, 2019

@dougburks

This comment has been minimized.

Copy link
Contributor Author

commented May 30, 2019

Bro 2.6.2 release (security update)
A security patch release, Bro v2.6.2, is now available for download:

  https://www.zeek.org/download/index.html

The following Denial of Service vulnerabilities are addressed:

* Integer type mismatches in BinPAC-generated parser code and Bro
  analyzer code may allow for crafted packet data to cause
  unintentional code paths in the analysis logic to be taken due to
  unsafe integer conversions causing the parser and analysis logic
  to each expect different fields to have been parsed.  One such
  example, reported by Maksim Shudrak, causes the Kerberos analyzer
  to dereference a null pointer.  CVE-2019-12175 was assigned for
  this issue.

* The Kerberos parser allows for several fields to be left
  uninitialized, but they were not marked with an &optional attribute
  and several usages lacked existence checks.  Crafted packet data
  could potentially cause an attempt to access such uninitialized
  fields, generate a runtime error/exception, and leak memory.
  Existence checks and &optional attributes have been added to the
  relevent Kerberos fields.

* BinPAC-generated protocol parsers commonly contain fields whose
  length is derived from other packet input, and for those that allow
  for incremental parsing, BinPAC did not impose a limit on how
  large such a field could grow, allowing for remotely-controlled
  packet data to cause growth of BinPAC's flowbuffer bounded only
  by the numeric limit of an unsigned 64-bit integer, leading
  to memory exhaustion.  There is now a generalized limit for
  how large flowbuffers are allowed to grow, tunable by setting
  "BinPAC::flowbuffer_capacity_max".

@dougburks dougburks moved this from To do to In progress in 16.04.6.2 May 30, 2019

@dougburks dougburks moved this from In progress to In Testing in 16.04.6.2 May 30, 2019

@dougburks

This comment has been minimized.

Copy link
Contributor Author

commented May 30, 2019

@dougburks

This comment has been minimized.

@dougburks dougburks closed this Jun 3, 2019

16.04.6.2 automation moved this from In Testing to Done Jun 3, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.