Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • aports aports
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Graph
    • Compare
  • Issues 656
    • Issues 656
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 333
    • Merge requests 333
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Releases
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • alpinealpine
  • aportsaports
  • Issues
  • #2195
Closed
Open
Issue created Aug 06, 2013 by Natanael Copa@ncopaOwner

quagga: CVE-2013-2236, stack overrun in apiserver

http://nongnu.uib.no//quagga/quagga-0.99.22.3.changelog.txt

commit 3f872fe60463a931c5c766dbf8c36870c0023e88
Author: David Lamparter <equinox@opensourcerouting.org>
Date:   Mon Jul 8 23:05:28 2013 +0200

    ospfd: CVE-2013-2236, stack overrun in apiserver

    the OSPF API-server (exporting the LSDB and allowing announcement of
    Opaque-LSAs) writes past the end of fixed on-stack buffers.  This leads
    to an exploitable stack overflow.

    For this condition to occur, the following two conditions must be true:
    - Quagga is configured with --enable-opaque-lsa
    - ospfd is started with the "-a" command line option

    If either of these does not hold, the relevant code is not executed and
    the issue does not get triggered.

    Since the issue occurs on receiving large LSAs (larger than 1488 bytes),
    it is possible for this to happen during normal operation of a network.
    In particular, if there is an OSPF router with a large number of
    interfaces, the Router-LSA of that router may exceed 1488 bytes and
    trigger this, leading to an ospfd crash.

    For an attacker to exploit this, s/he must be able to inject valid LSAs
    into the OSPF domain.  Any best-practice protection measure (using
    crypto authentication, restricting OSPF to internal interfaces, packet
    filtering protocol 89, etc.) will prevent exploitation.  On top of that,
    remote (not on an OSPF-speaking network segment) attackers will have
    difficulties bringing up the adjacency needed to inject a LSA.

    This patch only performs minimal changes to remove the possibility of a
    stack overrun.  The OSPF API in general is quite ugly and needs a
    rewrite.

    Reported-by: Ricky Charlet <ricky.charlet@hp.com>
    Cc: Florian Weimer <fweimer@redhat.com>
    Signed-off-by: David Lamparter <equinox@opensourcerouting.org>

(from redmine: issue id 2195, created on 2013-08-06, closed on 2013-08-30)

  • Relations:
    • child #2196 (closed)
    • child #2197 (closed)
    • child #2200 (closed)
    • child #2199 (closed)
  • Changesets:
    • Revision a28bace5 by Natanael Copa on 2013-08-06T15:10:40Z:
main/quagga: upgrade to 0.99.22.3

ref #2195
fixes #2196
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking