In the constant commotion caused by the seemingly ubiquitous Log4Shell Unsafe featuresSecurity breaches, it’s easy to forget all the other things you should and usually do in any way.
In fact, the UK’s National Cyber Security Centre (NCSC) Warned:
repair [the Log4Shell] For larger organizations, the problem may take weeks or months.
As it happens, the above quoted guidelines from the NSCS company board of directors, part of which warns senior management to take measures to avoid burnout of the cyber security team.
But we already need to write an article about Apple’s latest security updates this week. These updates apply to all of the company’s products and include fixes for almost every security risk you can think of.
Apple’s patches do not deal with Log4Shell, but they do close other vulnerabilities ranging from kernel compromise (think: spyware implantation) to privacy bypass (think: configuration hacking and data leakage):
On our sister site Sophos News, we wrote about Patch Tuesday, Microsoft fixed many operating system and application errors, including 26 remote code execution (RCE) defects.
Similarly, Log4Shell did not appear, but there are eight ironic RCEs in Microsoft’s own software tools designed to improve the security of the well-known fragile world of IoT devices:
OpenSSL release update
Well, in case you missed it, the famous OpenSSL encryption toolkit-we guess it is a free and open source software product with a much wider installation range than Log4J-also Published update this week.
Open SSL 1.1.1m Replace 1.1.1l (the last character is M-for-Mike and L-for-Lima) And OpenSSL 3.0.1 Replace 3.0.0.
If you are wondering, the popular XYZ version control scheme used by OpenSSL 3 was introduced, at least in part, to avoid confusion caused by trailing letters in the “numbering” system of earlier versions. As for OpenSSL 2, it doesn’t. Currently only supports 1.1.1 and 3.0 series, so updating OpenSSL 1.0.x and other versions means jumping to 1.1.1m, or jumping directly to OpenSSL 3 series.
“The application may not work properly”
The good news is that the OpenSSL 1.1.1m release notes did not list any errors with the CVE number, which shows that although this update is both desirable and important (OpenSSL is released very frequently, you can assume that they are purposeful), but you may not Need to consider its importance.
But those who have moved to OpenSSL 3-and, like your tax return, it is ultimately inevitable, and it will be a lot easier to some extent if you start early-what should be noted is OpenSSL 3.0.1 Patch a Security Risk Dubbing CVE-2021-4044.
As far as we know, there are no known viable vulnerabilities for this bug, but as the OpenSSL release notes point out:
[The error code that may be returned due to the bug] Will be completely unexpected, so the application may not work properly. The exact behavior will depend on the application, but it may cause crashes, infinite loops, or other similar error responses.
In theory, a precisely written application should not be vulnerable to this error, which is mentioned by us in the title Wrong merge, This is really just a peculiar way of saying, “We gave you the wrong result.”
Simply put, some internal errors in OpenSSL—a real but unlikely error, such as insufficient memory, or a defect elsewhere in OpenSSL that caused an error-free error—will not be reported correctly.
These errors do not penetrate back into your application exactly, but are “remapped” when they are passed back to the call chain in OpenSSL, where they end up showing up as completely different error types.
You can see artificial but explanatory examples of such errors in this code:
extern int open (const char *fname, int flags);
extern int close (int fd);
extern int read (int fd, void *buff, unsigned int len);
extern int printf(const char *fmt, ...);
/* Utility function to open file for reading */
static int openfile(const char *fname) {
/* Open file in mode 0 (O_RDONLY) */
return open(fname,0);
}
/* Utility function to read first 4 'magic' bytes of file */
static int readmagic(const char *fname) {
int magic, fd, nbytes;
/* Open file, return -1 on error */
if ((fd=openfile(fname)) < 0) { return -1; };
/* Try to read 'magic' number */
nbytes = read(fd,&magic,sizeof(int));
close(fd);
/* Return 'magic' if we got enough bytes */
/* or return -1 to denote error if not */
return nbytes < sizeof(int) ? -1 : magic;
}
/* Top-level code */
extern int main(int argc, char **argv) {
int magic, revmagic;
/* Try every file on command line */
for (int n = 1; n < argc; n++) {
/* Call the one true magic-finding function */
magic = readmagic(argv[n]);
/* Check for errors, and say so if needed */
if (magic == -1) {
printf("File %s is corruptn",argv[n]);
} else {
int revmagic = (((magic>>24)&255)<< 0)|
(((magic>>16)&255)<< 8)|
(((magic>> 8)&255)<<16)|
(((magic>> 0)&255)<<24);
printf("%-24s: magic = [",argv[n]);
for (int i = 0; i < 4; i++) {
char ch = *((char *)(&magic)+i);
printf("%c",ch>=32 && ch<127 ? ch : '.');
}
printf("] (0x%08X) %dn",revmagic,magic);
}
}
return 0;
}
Figure out the code
If you are not a programmer or don’t know C, don’t worry-this story is easy to tell.
This main() The above function attempts to read the first four bytes of the file specified on the command line, which is usually enough to guess the type of the file, and then print out this four-byte “magic” number in big-endian hexadecimal ASCII format, And expressed in signed decimal:
$ /home/duck/testapp/badmagic samples/* samples/class.gday : magic = [....] (0xCAFEBABE) -1095041334 samples/class.testapp : magic = [....] (0xCAFEBABE) -1095041334 samples/doc.format : magic = [....] (0xD0CF11E0) -535703600 samples/doc.legal5 : magic = [....] (0xD0CF11E0) -535703600 samples/docx.letter : magic = [PK..] (0x504B0304) 67324752 samples/exe.notepad : magic = [MZ..] (0x4D5A9000) 9460301 samples/exe.salamand : magic = [MZ..] (0x4D5A8000) 8411725 samples/jar.gday : magic = [PK..] (0x504B0304) 67324752 samples/png.logo : magic = [.PNG] (0x89504E47) 1196314761 samples/zip.archive : magic = [PK..] (0x504B0304) 67324752
Side note. This MZ In the EXE file is Mark Zbykowski, Who invented the file format decades ago.This PK Late in ZIP, DOCX and JAR files Phil Katz, The founder of PK-ZIP and the inventor of all these file formats.Hexadecimal Magic Number CAFEBABE and D0CF11E0 (Read the first 1 As I The second one is L) Used for compiled Java class files and old-style Office DOC files is a passport to programmatic humor.
Running as above, the program seems to be running well.
But all errors that the program may encounter will be converted into a single, convenient error code -1 (0xFFFFFFFF in hexadecimal), and any errors that occur will be reported as follows (this time, we are using Windows):
C:Usersduck> badmagic.exe 1byte.file nosuch.file ffffffff.raw C:Windows File 1byte.file is corrupt File nosuch.file is corrupt File ffffffff.raw is corrupt File C:Windows is corrupt
The code reports some kind of error every time, but the programmer tries to simplify error handling by assuming that any file of four bytes cannot be read, so there is no definition of a “magic” digital program in this regard, to some extent The above is “corrupt”.
Faced with the above output, you will think that something terrible has just happened to your hard disk or operating system. In fact, three of the errors are unexceptional and unremarkable, and one of them is not all of them.
If the low-level function openfile() and readmagic() Has been structured to allow them to return useful and true error codes, all the way back to the top level main() Function, the output may be laid out like this:
File 1byte.file contains fewer than 4 bytes File nosuch.file does not exist ffffffff.raw : magic = [....] (0xFFFFFFFF) -1 File C:Windows is a directory
In fact, the programmer made another mistake here, choosing a wrong value (-1) that overlaps with a possible, albeit unlikely, true answer.
document ffffffff.raw It consists of repeated hexadecimal bytes 0xFF, so the file does exist, not a directory, at least four bytes long, and should be reported as a magic number with 0xFFFFFFFF instead of being corrupted.
By conflating various errors and causing them without errors, readmagic() The function may send any higher-level parts of the application that use it for crazy chases, as well as wrong behavior that may mislead higher-level code.
Good coding habits
Well-written code should never ignore “errors that never happen at this time”, because such errors have bad habits that happen after all.
When well-written code records in its “contract” with the outside world that it cannot do so, it should never return an error. (If the code insists that “no error will occur” but something goes wrong, the code should either fix the error completely correctly or terminate abnormally.)
Well-written code should never pretend to be error-free.
It is worth noting that both Unix/Linux and Windows provide an official method for high-level code to more accurately amplify low-level errors that cannot be accurately reported by the function that detects it.
For example, the C function that returns the memory address has no choice but to use NULL (Usually a zero value) means an error, and anything else that means success, because NULL value is the only pointer defined as inaccessible and invalid.
Generally speaking, generally speaking, NULL It is a unique value guaranteed by the C standard not to conflict with any legal memory address that may be returned.
To solve this problem, you can check the special variable errno (Unix/Linux), or call Windows function GetLastError().
But neither of these two technologies can restore the previous error code: no GetSecondLastError() Function, and errno The variable is not an array of changing historical error codes.
Therefore, if an error is handled, another system function needs to be called—for example, if it fails read() A file means you close() Before you return-then you may find that when you return to the part of the app that called you, GetLastError() or errno Will be happy to tell the caller that there is no problem.
As Microsoft explained:
When the return value of the function indicates that such a call will return useful data, you should call the GetLastError function immediately.That’s because some functions [set the error code back to zero] When they succeed, the error code set by the most recently failed function is cleared.
OpenSSL irony
The irony is that perhaps only when OpenSSL attempts to improve security by verifying the digital certificate provided by the remote server will it trigger the OpenSSL 3.0.0 “error penetration” error.
As OpenSSL Consulting instructions, The first way to trigger this error is when an error (such as a memory error) is inadvertently returned to you as a “you need to try again” type of error.
In general, you should assume that you cannot reliably recover from memory errors, and that your software should be closed as cleanly as possible to avoid crashes or damage, so “trying again” is almost certainly the wrong approach.
The second method is that if a single, just-fixed OpenSSL error is not worth CVE by itself, even if no error occurs, it will trigger a false “you need to try again” error.
As you might imagine, say “you need to try again”, and all of this will happen, but another same error will happen. This is the secret of the trouble.
what to do?
- If you are using OpenSSL 1.1.1. Your customers may reasonably expect you to patch, but if you are still busy fighting Log4Shell, we want them to be reasonable instead of insisting on you to patch immediately. However, please note that automatic vulnerability scanning tools that only “detect” errors based on the version number string, rather than determining whether the errors are actually available or even accessible in the code they “analyze”, may generate warnings that make your The customer is in a hurry. be prepared.
- If you are using Open SSS 3.0.0. This error may not be serious and may not even be triggered in your code, but your easiest and fastest solution is to fix it to avoid all doubts.
- If you are a programmer. Try to keep and return real error messages, from the point where they happened all the way to your log file or console. “Losty” error reports can cause trouble troubleshooting at best because you misled the user. In the worst-case scenario, inaccurate or incorrect error messages can cause unsafe decisions to be made elsewhere in the code, such as pursuing purposefully when there is insufficient memory. Avoid using values that may appear legally to indicate errors, because the reported “problem” does not actually exist and can never be “resolved.”
Listen to our latest podcast – LOG4SHELL suggestion
Click and drag the sound wave below to jump to any point.you can also Listen directly On Soundcloud.
