The busybox NTP implementation doesn't check the NTP mode of packets received on the server port and responds to any packet with the right size. This includes responses from another NTP server. An attacker can send a packet with a spoofed source address in order to create an infinite loop of responses between two busybox NTP servers. Adding more packets to the loop increases the traffic between the servers until one of them has a fully loaded CPU and/or network.
It seems this bug was actually inherited from openntpd, on which the busybox implementation was based on. In openntpd it was fixed in:
https://github.com/openntpd-portable/openntpd-openbsd/commit/28a2f904aafbf4c209fe6fa04ffb9308740fd78a
Busybox upstream patch:
https://git.busybox.net/busybox/commit/?id=150dc7a2b483b8338a3e185c478b4b23ee884e71
It was found that doaproutch function in crypto/bio/bprint.c in OpenSSL 1.0.1 before 1.0.1s and 1.0.2 before 1.0.2g does not verify that a certain memory allocation succeeds, which allows remote attackers to cause a denial of service (out-of-bounds write or memory consumption) or possibly have unspecified other impact via a long string, as demonstrated by a large amount of ASN.1 data. This issues is different than CVE-2016-0799.
Upstream patch:
https://git.openssl.org/?p=openssl.git;a=commit;h=578b956fe741bf8e84055547b1e83c28dd902c73
As per Upstream advisory:
The internal |fmtstr| function used in processing a "%s" format string in the BIOprintf functions could overflow while calculating the length of a string and cause an OOB read when printing very long strings.
Additionally the internal |doaproutch| function can attempt to write to an OOB memory location (at an offset from the NULL pointer) in the event of a memory allocation failure. In 1.0.2 and below this could be caused where the size of a buffer to be allocated is greater than INTMAX. E.g. this could be in processing a very long "%s" format string. Memory leaks can also occur.
These issues will only occur on certain platforms where sizeof(sizet) > sizeof(int). E.g. many 64 bit systems. The first issue may mask the second issue dependent on compiler behaviour. These problems could enable attacks where large amounts of untrusted data is passed to the BIOprintf functions. If applications use these functions in this way then they could be vulnerable. OpenSSL itself uses these functions when printing out human-readable dumps of ASN.1 data. Therefore applications that print this data could be vulnerable if the data is from untrusted sources. OpenSSL command line applications could also be vulnerable where they print out ASN.1 data, or if untrusted data is passed as command line arguments.
Libssl is not considered directly vulnerable. Additionally certificates etc received via remote connections via libssl are also unlikely to be able to trigger these issues because of message size limits enforced within libssl.
This issue affects OpenSSL versions 1.0.2 and 1.0.1.
OpenSSL 1.0.2 users should upgrade to 1.0.2g OpenSSL 1.0.1 users should upgrade to 1.0.1s
This issue was reported to OpenSSL on February 23rd by Guido Vranken. The fix was developed by Matt Caswell of the OpenSSL development team.
Advantech Spectre RT ERT351 Versions 5.1.3 and prior logins and passwords are transmitted in clear text form, which may allow an attacker to intercept the request.
Advantech Spectre RT ERT351 Versions 5.1.3 and prior has insufficient login authentication parameters required for the web application may allow an attacker to gain full access using a brute-force password attack.
In Advantech Spectre RT Industrial Routers ERT351 5.1.3 and prior, the affected product does not neutralize special characters in the error response, allowing attackers to use a reflected XSS attack.