Backdoor code found in 11 Ruby libraries (ZDNet)

Posted Aug 24, 2019 2:13 UTC (Sat) by pizza (subscriber, #46)
In reply to: Backdoor code found in 11 Ruby libraries (ZDNet) by marcH
Parent article: Backdoor code found in 11 Ruby libraries (ZDNet)

None of these have anything to do with C or another "unsafe" language/runtime:

Data exfiltration via SQL injection due to unsanitized input.
Spectre/Meltdown was exploitable using pure javascript in a web browser
multi-GB repositories of personal data found on unsecured cloud storage
Crypto keys or other credentials in public github repos
The infamous "Debian OpenSSL fiasco" was due to a poorly-thought-out "optimization" by a packager
The entire certificate authority model -- including "every root cert is fully trusted" and poor vetting of certificates
Users that get their local account compromised by "opening" an email attachment
Windows using the file extension to determine executability, while also hiding the extension from users
Millions of wifi routers, cameras, and so forth having hardcoded default credentials accessible from the internet

....and many, many more.

Backdoor code found in 11 Ruby libraries (ZDNet)

Posted Aug 24, 2019 14:51 UTC (Sat) by marcH (subscriber, #57642) [Link]

> > Which statistics and other measurements is this based on?

> many, many

Backdoor code found in 11 Ruby libraries (ZDNet)

Posted Aug 26, 2019 8:53 UTC (Mon) by LtWorf (subscriber, #124958) [Link] (1 responses)

> The infamous "Debian OpenSSL fiasco" was due to a poorly-thought-out "optimization" by a packager

Well not quite, he did ask on the openssl mailing list and they told him to go ahead and make the change to reset the buffer.

Also Luciano Bello, the guy who found the issue has said this, that the blame doesn't entirely rest with the debian maintainer.

Backdoor code found in 11 Ruby libraries (ZDNet)

Posted Aug 27, 2019 21:19 UTC (Tue) by ncm (guest, #165) [Link]

There is more that enough blame to go around.

Backdoor code found in 11 Ruby libraries (ZDNet)

Posted Aug 27, 2019 8:19 UTC (Tue) by dvdeug (guest, #10998) [Link] (2 responses)

For one, there's no numbers here. I could quote my own things:

prosfilaes@asimov:~$ zless /usr/share/doc/libtiff5/changelog.Debian.gz
tiff (4.0.10+git190818-1) unstable; urgency=high

* Git snapshot, fixing the following security issues:
- RGBA interface: fix integer overflow potentially causing write heap
buffer overflow,
- setByteArray(): avoid potential signed integer overflow.

-- Laszlo Boszormenyi (GCS) <gcs@debian.org> Sun, 18 Aug 2019 11:25:27 +0000

tiff (4.0.10+git190814-1) unstable; urgency=high

* Git snapshot, fixing the following security issues:
- TryChopUpUncompressedBigTiff(): avoid potential division by zero,
- fix vulnerability introduced by defer strile loading,
- fix vulnerability in 'D' (DeferStrileLoad) mode,
- return infinite distance when denominator is zero,
- OJPEG: avoid use of uninitialized memory on corrupted files,
- OJPEG: fix integer division by zero on corrupted subsampling factors,
- OJPEGReadBufferFill(): avoid very long processing time on corrupted
files,
- TIFFClientOpen(): fix memory leak if one of the required callbacks is
not provided,
- CVE-2019-14973, fix integer overflow in _TIFFCheckMalloc() and other
implementation-defined behaviour (closes: #934780).
* Update libtiff5 symbols.
* Update Standards-Version to 4.4.0 .

-- Laszlo Boszormenyi (GCS) <gcs@debian.org> Wed, 14 Aug 2019 19:24:22 +0000

tiff (4.0.10-4) unstable; urgency=high

* Backport security fixes:
- CVE-2018-12900: heap-based buffer overflow in
cpSeparateBufToContigBuf() cause remote DoS (closes: #902718),
- CVE-2018-17000: NULL pointer dereference in _TIFFmemcmp() cause DoS
(closes: #908778),
- CVE-2018-19210: NULL pointer dereference in TIFFWriteDirectorySec()
cause DoS (closes: #913675),
- CVE-2019-6128: TIFFFdOpen() memory leak (closes: #921157).
* Update watch file.
* Update Standards-Version to 4.3.0 .

-- Laszlo Boszormenyi (GCS) <gcs@debian.org> Sat, 02 Feb 2019 18:34:29 +0000

Pretty good for "hypothetical, simple errors in C code", huh? Not to mention that you have two errors in your examples:

At least many "data exfiltration via SQL injection due to unsanitized input" problems are due to bugs in language or library runtimes. A properly designed SQL library will at the least discourage unsanitized input.

The infamous "Debian OpenSSL fiasco" was not due to a poorly-thought-out "optimization" by a packager. It was an incorrect fix to a problem caused by C being unsafe; Valgrind turned up that OpenSSL was using uninitialized data to create its keys, and the developer decided to fix that, accidentally taking out much of the rest of data used to create the keys.

Backdoor code found in 11 Ruby libraries (ZDNet)

Posted Aug 27, 2019 12:06 UTC (Tue) by pizza (subscriber, #46) [Link] (1 responses)

> A properly designed SQL library will at the least discourage unsanitized input.

As long as that library allows the programmer to supply raw SQL query text, it will be vulnerable to unsanitized input.

(Meanwhile, I maintain a largely-moribund 27KLOC PHP project. When I started contributing to it, PHP's SQL libraries didn't even support named parameters, and while now I can finally rely on PHP::PDO being present, I simply can't justify going back and substantially rewriting most of it. Because my family needs to eat.)

Backdoor code found in 11 Ruby libraries (ZDNet)

Posted Aug 27, 2019 16:30 UTC (Tue) by dvdeug (guest, #10998) [Link]

There's systems like LINQ that don't allow the programmer to supply raw SQL query text. In any case, there's levels; Ada compilers will let you turn off bounds checking, but that's still better than C++ that offers bounds checking on many things but not standard arrays, which is better than C which offers no bounds-checked list/vector type and no way to make a new type that syntactically works like the array type.

Your PHP example is exactly why I'd call SQL injection at least partially a programming language/library problem.