If anyone knows, I would be thankfull for the answer.

Prior to 4.x Mikrotik were using Quagga, but I believe the current BGP implementation was developed in-house.

I would not be surprised if Mikrotik are using parts of Quagga with some additional in-house developed modules, the zserv API makes that easy....

Prior to 4.x Mikrotik were using Quagga, but I believe the current BGP implementation was developed in-house.

I would not be surprised if Mikrotik are using parts of Quagga with some additional in-house developed modules, the zserv API makes that easy....

I was talking about this with a friend, a few months ago, and we discussed if Quagga still running as routing engine for x86. MikroTik changed to his own routing engine because of CCRs?

If Mikrotik use Quagga fork, then it may be worth fixing, cos I'm experiencing DenialOfService since last 48hrs on BOTH , independant bgp routers... Still diagnosing though.

BGP Flaws Patched in Quagga Routing Software
Friday, 16 February 2018 Administrator Security News 0 Comments
Several vulnerabilities that could lead to denial-of-service (DoS), information disclosure, and remote code execution have been patched this week in the Quagga routing software suite.

Quagga implements the Open Shortest Path First (OSPF), Routing Information Protocol (RIP), Border Gateway Protocol (BGP) and Intermediate System to Intermediate System (IS-IS) protocols for Unix-like platforms, particularly Linux, Solaris, FreeBSD and NetBSD.

Quagga developers and the CERT Coordination Center (CERT/CC) at Carnegie Mellon University announced this week that Quagga 1.2.3 patches several vulnerabilities affecting the BGP daemon (bpgd).

One of the more serious flaws, rated critical by CERT/CC based on its CVSS score, is CVE-2018-5379, a double-free memory corruption issue related to the processing of certain UPDATE messages containing cluster-list or unknown attributes.

“This issue can be triggered by an optional/transitive UPDATE attribute, that all conforming eBGP speakers should pass along. This means this may triggerable in many affected Quagga bgpd processes across a wide area of a network, because of just one UPDATE message,” Quagga developers explained. “This issue could result in a crash of bgpd, or even allow a remote attacker to gain control of an affected bgpd process.”

Another vulnerability, CVE-2018-5381, can be exploited to cause bgpd to enter an infinite loop and stop responding until it’s restarted. “BGP sessions will drop and not be reestablished,” developers said.

Quagga 1.2.3 also patches CVE-2018-5378, a security hole that can lead to sensitive data from the bgpd process being sent over the network to a configured peer. This can also cause the bgpd process to crash.

The last vulnerability patched by the latest Quagga release is CVE-2018-5378, which developers say has “very low” impact.

Linux distributions, including Ubuntu, Debian and Red Hat, have started publishing advisories describing these vulnerabilities. Regarding CVE-2018-5379, Red Hat said “Glibc's heap protection mitigations render this issue more difficult to exploit, though bypasses may still be possible.”

Related: Google Finds Flaws in Dnsmasq Network Services Tool

Related: Many Vulnerabilities Found in Linux USB Subsystem

Related: Two-Year Old Vulnerability Patched in Linux Kernel

Original link
Original author: Eduard Kovacs

Quagga Security Note 2018-1975
==============================

https://www.quagga.net/security/Quagga-2018-1975.txt


Affects:
--------

- Quagga version 0.99.9, and all later versions
- All versions, if the "override-capability" neighbour option is set (not
the default).


Summary
-------

The Quagga BGP daemon, bgpd, can enter an infinite loop if sent an invalid
OPEN message by a configured peer.


Impact
------

This problem is triggerable by packets from a configured peer.

When triggered, the bgpd daemon enters an infinite loop and cease to respond
to any other events. BGP sessions will drop and not be reestablished. The
CLI interface will be unresponsive. The bgpd daemon will stay in this state
until it is restarted.


Solution
--------

Upgrade to Quagga version 1.2.3 or later, or apply the fix from commit:

"bgpd/security: fix infinite loop on certain invalid OPEN messages"

Until then, the problem can be mitigated by enabling watchquagga and
ensuring that it monitors bgpd and restarts it if it ceases to be
responsive.

Disabling capability negotiation will also prevent the problem from
occurring, but may cause problems. It is not recommended to disable
capability negotiation in normal operation.


Description
------------

The Quagga BGP daemon, bgpd, had a bug in its parsing of "Capabilities" in
BGP OPEN messages, in the bgp_packet.c:bgp_capability_msg_parse function.
The parser can enter an infinite loop on invalid capabilities if a
Multi-Protocol capability does not have a recognised AFI/SAFI.

The issue was introduced in commit 6d58272b4c, by copying an incorrect
pattern of code from an existing check on a configuration flag (which also
has the issue) and applying it to protocol data.

This issue can be triggered by a configured peer, accidentally or
deliberately. It could also be configured by others, if transport security
and/or network topology allowed an attacker to spoof a full TCP connection.

The consequence of this bug is that bgpd enters an infinite loop. The bgpd
daemon will not be able to do any other work as a consequence, including
servicing BGP and CLI sessions. BGP sessions will time out and drop and not
be re-established. This state will persist until the bgpd is restarted.

Quagga Security Note 2018-1114
==============================

https://www.quagga.net/security/Quagga-2018-1114.txt


Affects:
--------

- Likely to affect all versions of Quagga

Summary
-------

The Quagga BGP daemon, bgpd, can double-free memory when processing
certain forms of UPDATE message, containing cluster-list and/or unknown
attributes.

Impact
------

Potentially severe.

This issue can be triggered by an optional/transitive UPDATE attribute, that
all conforming eBGP speakers should pass along. This means this may
triggerable in many affected Quagga bgpd processes across a wide area of a
network, because of just one UPDATE message.

This issue could result in a crash of bgpd, or even allow a remote
attacker to gain control of an affected bgpd process.

Solution
--------

Upgrade to Quagga 1.2.3, or any other version with the appropriate
patch applied, entitled:

"bgpd/security: Fix double free of unknown attribute"

Description
------------

The issue is a double-free in bgp_attr_flush called from
bgp_packet.c:bgp_update_receive. This can be triggered by a variety of
BGP UPDATE messages, containing either a "CLUSTER_LIST" attribute (used
in iBGP route-reflection) or an unknown attribute.

An unrecognised optional/transitive UPDATE attribute should be passed along
by conforming BGP speakers, if the attribute is otherwise well-formed.
Therefore this issue potentially can be triggered across a number of Quagga
bgpd speakers, over a wide area of a network, by one BGP speaker sending an
UPDATE.

Once this issue has been triggered the behaviour of bgpd is undefined. The
internal state of the memory allocator may become corrupted, unless it has
been designed to be robust to the double-free. The memory allocator may
catch the issue and crash the bgpd process in a controlled manner, otherwise
bgpd process could continue to run with invalid memory allocation state.

It is possible an attacker could exploit the corrupted allocator state to
gain control of the bgpd process. E.g., if the allocator stores the
incorrectly double-freed memory twice on its internal free-list, then the
allocator could return the same memory twice in further calls of malloc, and
the attacker might be able to control the operation of one part of bgpd with
data they supply that is stored in another.

I think it may be worth to proceed with extensive security audit of Mikrotik BGP implementation...

I think it may be worth to proceed with extensive security audit of Mikrotik BGP implementation...

It's not Quagga!

Also, I can see some clear misunderstanding. BGP is a routing "control" protocol. It does no forwarding of packets so changing/upgrading BGP engine will have no effect on the packet forwarding performance of Mikrotik routers either CCR's, x86 or CHR.

I think it may be worth to proceed with extensive security audit of Mikrotik BGP implementation...

It's not Quagga!

Also, I can see some clear misunderstanding. BGP is a routing "control" protocol. It does no forwarding of packets so changing/upgrading BGP engine will have no effect on the packet forwarding performance of Mikrotik routers either CCR's, x86 or CHR.

Do You know what fork is ?
They might forked quagga, and vulnerable parts mau be there, if not modified.
Also, afaik death of bgp engine cause whole routing package to die, as I readen and observed myself.