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.
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.