Debian Linux Security Advisory 5281-1 - It was discovered that parsing errors in the mp4 module of Nginx, a high-performance web and reverse proxy server, could result in denial of service, memory disclosure or potentially the execution of arbitrary code when processing a malformed mp4 file.

    -----BEGIN PGP SIGNED MESSAGE-----Hash: SHA512- -------------------------------------------------------------------------Debian Security Advisory DSA-5281-1                   security@debian.orghttps://www.debian.org/security/                       Moritz MuehlenhoffNovember 15, 2022                     https://www.debian.org/security/faq- -------------------------------------------------------------------------Package        : nginxCVE ID         : CVE-2022-41741 CVE-2022-41742It was discovered that parsing errors in the mp4 module of Nginx, ahigh-performance web and reverse proxy server, could result in denialof service, memory disclosure or potentially the execution of arbitrarycode when processing a malformed mp4 file.This module is only enabled in the nginx-extras binary package.For the stable distribution (bullseye), these problems have been fixed inversion 1.18.0-6.1+deb11u3.We recommend that you upgrade your nginx packages.For the detailed security status of nginx please refer toits security tracker page at:https://security-tracker.debian.org/tracker/nginxFurther information about Debian Security Advisories, how to applythese updates to your system and frequently asked questions can befound at: https://www.debian.org/security/Mailing list: debian-security-announce@lists.debian.org-----BEGIN PGP SIGNATURE-----iQIzBAEBCgAdFiEEtuYvPRKsOElcDakFEMKTtsN8TjYFAmNz9JcACgkQEMKTtsN8Tjb4tg/7BRkAkF48UvvRjLolxVVuV1paSTRG8ArEeW3fHyA0fxs2UMuRL4ic1vqci3wxAAfHvYoOnk+QBY20Ly2MN7S7OukNovKE9AZCPulyYkVjtIWNSBeY0PzCU60yRP/KCZAGoGEYi6s4SUrK194ved+7jIcybgLvvGA8FRKW3wTRvzRGMfR6NTLuP7B3th0C5+KkapE8G5XlHWOIjv1h3Ok40cua7LtYx9RTITJ+wClvkJ6gPcCXXj/CnWWaPUvuEBwyr0PEBXfL9v1P8Eq1MmN+mWU9KeLYxIC+vcJxtpsYL67tMHIGTlDUgDVEFrXrDXi7XP/6hjl7t/J/cTPEwy/twX0emUQcUDlRNlOxh3skSmdPJP7DMu+t9UtQsuepgZ+oHfHh3gs9EWz2zRqbsVO03NjhKo9ebIjhe3H0P39cX3NN5qlSJeNTY45kVBDecnPQnhYqYuzqwXy5ZoUQDcU0Bo7zaUzeYhUsfXqrROV/tj+UTMrM2anHdQ4BkAOrCBpmGP1lLvDs2PzBcWmBtII/5VTKZep05xH0L+dZWDV07j1ekCzv3/kuKiMlGTJQ7yl3fgKjLdkjMFKQIfsm3xdYwzxjOmtEY86tUV0LjtdR2GlJtF4YdIQhA4b1/R82ZisLfmZ4ElL+ua8iypLOe9reyO4EpVVDkeewFS64Ye1Wn3k=3mDY-----END PGP SIGNATURE-----

Debian Security Advisory 5281-1

Server Side Request Forgery (SSRF) vulnerability in All in One SEO Pro plugin <= 4.2.5.1 on WordPress.

CVE-2022-42494: AIOSEO Changelog - AIOSEO

An information leakage vulnerability in the Bluetooth Low Energy advertisement scan response in Bluetooth Core Specifications 4.0 through 5.2, and extended scan response in Bluetooth Core Specifications 5.0 through 5.2, may be used to identify devices using Resolvable Private Addressing (RPA) by their response or non-response to specific scan requests from remote addresses. RPAs that have been associated with a specific remote device may also be used to identify a peer in the same manner by using its reaction to an active scan request. This has also been called an allowlist-based side channel.

CVE-2020-35473: ACM CCS 2022

Containers and their supporting infrastructure are too important to ignore.

How will threat actors attack and utilize containers? This is a question I constantly think about. I've been working in this area for more than two decades now, and I feel like I should have an answer. But I don't.

Instead, I have a lot of different ideas, none of which I can really pinpoint as correct. Part of this indecision is because of all the time I spent learning security in the "legacy" world. Containers do not really have an analog. Sure, virtual machines (VMs) are often conflated with containers, but they were never able to scale like containers. They are also used for completely different purposes than containers. It's taken a while to adjust my thinking and understand where containers actually fit into the attack surface.

The public examples of attacks against containerized environments are very limited. The breaches almost always are cryptomining related, which are serious attacks, but the incident responder in me finds them underwhelming. Another commonality is they are mostly the result of a misconfiguration, whether that be in Kubernetes or a cloud account. The combination of the motives and the tactics have not been very inspiring so far.

**The Old Way**

Remote code execution (RCE) vulnerabilities have been the main concern in computer security for a long time. They are still, but how does this way of thinking apply to containers? It's easy to immediately jump to RCE as the primary threat, but it doesn't seem to be the right way to approach containers. For one thing, containers are often very short lived – 44% of containers live less than five minutes – so an intruder would have to be quick.

This approach also assumes that the container is exposed to the Internet. Certainly some containers are set up this way, but they often are very simple and use well-tested technologies, like NGINX. There may be zero-days out for these applications, but they would be extremely valuable and hard to come by. My experience has shown me that a lot of containers are used internally and don't connect directly to the Internet. The RCE scenario gets a lot more difficult in that case. I should mention Log4j, though these sorts of vulnerabilities have the potential of being exploited remotely even if the vulnerable system isn't on the edge.

**The New Way**

If RCE isn't the biggest threat facing containers, then what is? Are containers even on the radar of threat actors? Yes, containers and their supporting infrastructure are too important to ignore. Container orchestration software has allowed containerized workloads to be scaled to unimaginable numbers. The usage trend is also increasing, so you can be sure they will be a target. They just can't be thought of like servers you get at through RCE vulnerabilities.

Instead, the reverse is actually true. Instead of attacking containers from the outside in, they need to be attacked from the inside out. This is essentially what supply chain attacks do. Supply chain is an extremely effective attack vector against containers when you start to understand how they are built. A container starts with a definition file, such as Dockerfile, which defines everything that will be in the container when it runs. It is turned into an image once built, and that image is what may be spun up into a workload an innumerable amount of times. If anything in that definition file is compromised, then every single workload that runs is compromised.

Containers are often, but not always, purpose-built with an application that does something and exits. These applications can be almost anything — the important thing to understand is how much is built using libraries, either closed source or open source, written by other people. GitHub has millions of projects, and that's not the only repository of code out there. As we saw with SolarWinds, closed source is vulnerable to supply chain attacks as well.

A supply chain attack is a great way for threat actors to get into a target's container environment. They can even let the customer's infrastructure scale their attack for them if the compromise goes unnoticed. This type of scenario is already playing itself out, as we saw with the Codecov breach. But it is difficult to detect due to how new all of this is and how our thinking is still rooted in the problems of the past.

**A Way Forward**

As with fixing most problems, visibility is usually a great place to start. It's hard to fix what you can't see. To secure your containers you need to have visibility into the containers themselves, as well as the whole pipeline that builds them. Vulnerability management is one type of visibility that must be integrated into the build pipeline. I would also include other static analysis tools, such as ones that look for leaked secrets to that as well. Since what a supply chain attack looks like can't really be predicted, runtime monitoring becomes critical so you know exactly what your containers are doing.

Where Are All of the Container Breaches?

Nginx NJS v0.7.2 to v0.7.4 was discovered to contain a segmentation violation via njs_scope_valid_value at njs_scope.h.

    OS      : Linux ubuntu 5.13.0-27-generic #29~20.04.1-Ubuntu SMP Fri Jan 14 00:32:30 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
    Commit  : 7bd570b39297d3d91902c93a624c89b08be7a6fe
    Version : 0.7.2
    Build   : 
              NJS_CFLAGS="$NJS_CFLAGS -fsanitize=address"
              NJS_CFLAGS="$NJS_CFLAGS -fno-omit-frame-pointer"
    

    function main() {
    function a0(a1,a2) {
        a0 = a1;
    }
    a0();
    a0();
    }
    main();
    

    AddressSanitizer:DEADLYSIGNAL
    =================================================================
    ==2064564==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x0000004e36b5 bp 0x7ffd26e5c130 sp 0x7ffd26e5b920 T0)
    ==2064564==The signal is caused by a READ memory access.
    ==2064564==Hint: address points to the zero page.
        #0 0x4e36b5 in njs_scope_valid_value /home/q1iq/Documents/origin/njs/src/njs_scope.h:85:10
        #1 0x4e36b5 in njs_vmcode_function_copy /home/q1iq/Documents/origin/njs/src/njs_vmcode.c:1223:14
        #2 0x4e36b5 in njs_vmcode_interpreter /home/q1iq/Documents/origin/njs/src/njs_vmcode.c:727:23
        #3 0x53b43a in njs_function_lambda_call /home/q1iq/Documents/origin/njs/src/njs_function.c:703:11
        #4 0x4e47fa in njs_vmcode_interpreter /home/q1iq/Documents/origin/njs/src/njs_vmcode.c:785:23
        #5 0x53b43a in njs_function_lambda_call /home/q1iq/Documents/origin/njs/src/njs_function.c:703:11
        #6 0x4e47fa in njs_vmcode_interpreter /home/q1iq/Documents/origin/njs/src/njs_vmcode.c:785:23
        #7 0x4deb7b in njs_vm_start /home/q1iq/Documents/origin/njs/src/njs_vm.c:493:11
        #8 0x4c8099 in njs_process_script /home/q1iq/Documents/origin/njs/src/njs_shell.c:903:19
        #9 0x4c7484 in njs_process_file /home/q1iq/Documents/origin/njs/src/njs_shell.c:632:11
        #10 0x4c7484 in main /home/q1iq/Documents/origin/njs/src/njs_shell.c:316:15
        #11 0x7f135ab960b2 in __libc_start_main /build/glibc-eX1tMB/glibc-2.31/csu/../csu/libc-start.c:308:16
        #12 0x41dabd in _start (/home/q1iq/Documents/origin/njs/build/njs+0x41dabd)
    
    AddressSanitizer can not provide additional info.
    SUMMARY: AddressSanitizer: SEGV /home/q1iq/Documents/origin/njs/src/njs_scope.h:85:10 in njs_scope_valid_value
    ==2064564==ABORTING

CVE-2022-43284: SEGV njs_scope.h:85:10 in njs_scope_valid_value · Issue #470 · nginx/njs

Nginx NJS v0.7.2 was discovered to contain a heap-use-after-free bug caused by illegal memory copy in the function njs_json_parse_iterator_call at njs_json.c.

@@ -28,27 +28,17 @@ typedef struct { int64\_t length; njs\_array\_t \*keys; njs\_value\_t \*key; njs\_object\_prop\_t \*prop; njs\_value\_t prop; } njs\_json\_state\_t;  
  
typedef struct { njs\_value\_t retval;  
njs\_uint\_t depth; #define NJS\_JSON\_MAX\_DEPTH 32 njs\_json\_state\_t states\[NJS\_JSON\_MAX\_DEPTH\];  
njs\_function\_t \*function; } njs\_json\_parse\_t;  
  
typedef struct { njs\_value\_t retval;  
njs\_vm\_t \*vm;  
njs\_uint\_t depth; #define NJS\_JSON\_MAX\_DEPTH 32 njs\_json\_state\_t states\[NJS\_JSON\_MAX\_DEPTH\];  
njs\_value\_t replacer; @@ -72,10 +62,9 @@ njs\_inline uint32\_t njs\_json\_unicode(const u\_char \*p); static const u\_char \*njs\_json\_skip\_space(const u\_char \*start, const u\_char \*end);  
static njs\_int\_t njs\_json\_parse\_iterator(njs\_vm\_t \*vm, njs\_json\_parse\_t \*parse, njs\_value\_t \*value); static njs\_int\_t njs\_json\_parse\_iterator\_call(njs\_vm\_t \*vm, njs\_json\_parse\_t \*parse, njs\_json\_state\_t \*state); static njs\_int\_t njs\_json\_internalize\_property(njs\_vm\_t \*vm, njs\_function\_t \*reviver, njs\_value\_t \*holder, njs\_value\_t \*name, njs\_int\_t depth, njs\_value\_t \*retval); static void njs\_json\_parse\_exception(njs\_json\_parse\_ctx\_t \*ctx, const char \*msg, const u\_char \*pos);  
@@ -108,15 +97,13 @@ njs\_json\_parse(njs\_vm\_t \*vm, njs\_value\_t \*args, njs\_uint\_t nargs, njs\_index\_t unused) { njs\_int\_t ret; njs\_value\_t \*text, value, lvalue; njs\_value\_t \*text, value, lvalue, wrapper; njs\_object\_t \*obj; const u\_char \*p, \*end; njs\_json\_parse\_t \*parse, json\_parse; const njs\_value\_t \*reviver; njs\_string\_prop\_t string; njs\_json\_parse\_ctx\_t ctx;  
parse = &json\_parse;  
text = njs\_lvalue\_arg(&lvalue, args, nargs, 1);  
if (njs\_slow\_path(!njs\_is\_string(text))) { @@ -156,11 +143,16 @@ njs\_json\_parse(njs\_vm\_t \*vm, njs\_value\_t \*args, njs\_uint\_t nargs,  
reviver = njs\_arg(args, nargs, 2);  
if (njs\_slow\_path(njs\_is\_function(reviver) && njs\_is\_object(&value))) { parse->function = njs\_function(reviver); parse->depth = 0; if (njs\_slow\_path(njs\_is\_function(reviver))) { obj = njs\_json\_wrap\_value(vm, &wrapper, &value); if (njs\_slow\_path(obj == NULL)) { return NJS\_ERROR; }  
return njs\_json\_parse\_iterator(vm, parse, &value); return njs\_json\_internalize\_property(vm, njs\_function(reviver), &wrapper, njs\_value\_arg(&njs\_string\_empty), 0, &vm->retval); }  
vm->retval = value; @@ -851,195 +843,106 @@ njs\_json\_skip\_space(const u\_char \*start, const u\_char \*end) }  
  
static njs\_json\_state\_t \* njs\_json\_push\_parse\_state(njs\_vm\_t \*vm, njs\_json\_parse\_t \*parse, njs\_value\_t \*value) { njs\_json\_state\_t \*state;  
if (njs\_slow\_path(parse->depth >= NJS\_JSON\_MAX\_DEPTH)) { njs\_type\_error(vm, "Nested too deep or a cyclic structure"); return NULL; }  
state = &parse->states\[parse->depth++\]; state->value = \*value; state->index = 0; state->prop = NULL; state->keys = njs\_value\_own\_enumerate(vm, value, NJS\_ENUM\_KEYS, NJS\_ENUM\_STRING, 0); if (state->keys == NULL) { return NULL; }  
return state; }  
  
njs\_inline njs\_json\_state\_t \* njs\_json\_pop\_parse\_state(njs\_vm\_t \*vm, njs\_json\_parse\_t \*parse) { njs\_json\_state\_t \*state;  
state = &parse->states\[parse->depth - 1\]; njs\_array\_destroy(vm, state->keys); state->keys = NULL;  
if (parse->depth > 1) { parse->depth\--; return &parse->states\[parse->depth - 1\]; }  
return NULL; }  
  
static njs\_int\_t njs\_json\_parse\_iterator(njs\_vm\_t \*vm, njs\_json\_parse\_t \*parse, njs\_value\_t \*object) njs\_json\_internalize\_property(njs\_vm\_t \*vm, njs\_function\_t \*reviver, njs\_value\_t \*holder, njs\_value\_t \*name, njs\_int\_t depth, njs\_value\_t \*retval) { njs\_int\_t ret; njs\_value\_t \*key, wrapper; njs\_object\_t \*obj; njs\_json\_state\_t \*state; njs\_object\_prop\_t \*prop; njs\_property\_query\_t pq; int64\_t k, length; njs\_int\_t ret; njs\_value\_t val, new\_elem, index; njs\_value\_t arguments\[3\]; njs\_array\_t \*keys;  
obj = njs\_json\_wrap\_value(vm, &wrapper, object); if (njs\_slow\_path(obj == NULL)) { if (njs\_slow\_path(depth++ >= NJS\_JSON\_MAX\_DEPTH)) { njs\_type\_error(vm, "Nested too deep or a cyclic structure"); return NJS\_ERROR; }  
state = njs\_json\_push\_parse\_state(vm, parse, &wrapper); if (njs\_slow\_path(state == NULL)) { ret = njs\_value\_property(vm, holder, name, &val); if (njs\_slow\_path(ret == NJS\_ERROR)) { return NJS\_ERROR; }  
for ( ;; ) { if (state->index < state->keys\->length) { njs\_property\_query\_init(&pq, NJS\_PROPERTY\_QUERY\_SET, 0);  
key = &state->keys\->start\[state->index\];  
ret = njs\_property\_query(vm, &pq, &state->value, key); if (njs\_slow\_path(ret != NJS\_OK)) { if (ret == NJS\_DECLINED) { state->index++; continue; } keys = NULL;  
if (njs\_is\_object(&val)) { if (!njs\_is\_array(&val)) { keys = njs\_array\_keys(vm, &val, 0); if (njs\_slow\_path(keys == NULL)) { return NJS\_ERROR; }  
prop = pq.lhq.value;  
if (prop->type == NJS\_WHITEOUT) { state->index++; continue; }  
state->prop = prop; for (k = 0; k < keys->length; k++) { ret = njs\_json\_internalize\_property(vm, reviver, &val, &keys->start\[k\], depth, &new\_elem);  
if (prop->type == NJS\_PROPERTY && njs\_is\_object(&prop->value)) { state = njs\_json\_push\_parse\_state(vm, parse, &prop->value); if (state == NULL) { return NJS\_ERROR; if (njs\_slow\_path(ret != NJS\_OK)) { goto done; }  
continue; } if (njs\_is\_undefined(&new\_elem)) { ret = njs\_value\_property\_delete(vm, &val, &keys->start\[k\], NULL, 0);  
if (prop->type == NJS\_PROPERTY\_REF && njs\_is\_object(prop->value.data.u.value)) { state = njs\_json\_push\_parse\_state(vm, parse, prop->value.data.u.value); if (state == NULL) { return NJS\_ERROR; } else { ret = njs\_value\_property\_set(vm, &val, &keys->start\[k\], &new\_elem); }  
continue; if (njs\_slow\_path(ret == NJS\_ERROR)) { goto done; } }  
} else { state = njs\_json\_pop\_parse\_state(vm, parse); if (state == NULL) { vm->retval = parse->retval; return NJS\_OK; } }  
ret = njs\_json\_parse\_iterator\_call(vm, parse, state); if (njs\_slow\_path(ret != NJS\_OK)) { return ret; } } }  
  
static njs\_int\_t njs\_json\_parse\_iterator\_call(njs\_vm\_t \*vm, njs\_json\_parse\_t \*parse, njs\_json\_state\_t \*state) { njs\_int\_t ret; njs\_value\_t arguments\[3\], \*value; njs\_object\_prop\_t \*prop;  
prop = state->prop;  
arguments\[0\] = state->value; arguments\[1\] = state->keys\->start\[state->index++\];  
switch (prop->type) { case NJS\_PROPERTY: arguments\[2\] = prop->value; ret = njs\_object\_length(vm, &val, &length); if (njs\_slow\_path(ret == NJS\_ERROR)) { return NJS\_ERROR; }  
ret = njs\_function\_apply(vm, parse->function, arguments, 3, &parse->retval); if (njs\_slow\_path(ret != NJS\_OK)) { return ret; } for (k = 0; k < length; k++) { ret = njs\_int64\_to\_string(vm, &index, k); if (njs\_slow\_path(ret != NJS\_OK)) { return NJS\_ERROR; }  
if (njs\_is\_undefined(&parse->retval)) { prop->type = NJS\_WHITEOUT; ret = njs\_json\_internalize\_property(vm, reviver, &val, &index, depth, &new\_elem);  
} else { prop->value = parse->retval; } if (njs\_slow\_path(ret != NJS\_OK)) { return NJS\_ERROR; }  
break; if (njs\_is\_undefined(&new\_elem)) { ret = njs\_value\_property\_delete(vm, &val, &index, NULL, 0);  
case NJS\_PROPERTY\_REF: value = prop->value.data.u.value; arguments\[2\] = \*value; } else { ret = njs\_value\_property\_set(vm, &val, &index, &new\_elem); }  
ret = njs\_function\_apply(vm, parse->function, arguments, 3, &parse->retval); if (njs\_slow\_path(ret != NJS\_OK)) { return ret; if (njs\_slow\_path(ret == NJS\_ERROR)) { return NJS\_ERROR; } } } }  
if (njs\_is\_undefined(&parse->retval)) { ret = njs\_value\_property\_i64\_delete(vm, &state->value, state->index - 1, NULL);  
} else { ret = njs\_value\_property\_i64\_set(vm, &state->value, state->index - 1, &parse->retval); } njs\_value\_assign(&arguments\[0\], holder); njs\_value\_assign(&arguments\[1\], name); njs\_value\_assign(&arguments\[2\], &val);  
if (njs\_slow\_path(ret == NJS\_ERROR)) { return NJS\_ERROR; } ret = njs\_function\_apply(vm, reviver, arguments, 3, retval);  
break; done:  
default: njs\_internal\_error(vm, "njs\_json\_parse\_iterator\_call() unexpected " "property type:%s", njs\_prop\_type\_string(prop->type)); if (keys != NULL) { njs\_array\_destroy(vm, keys); }  
return NJS\_OK; return ret; }

CVE-2022-43286: Fixed JSON.parse() when reviver function is provided. · nginx/njs@2ad0ea2

Nginx NJS v0.7.4 was discovered to contain a segmentation violation in njs_promise_reaction_job.

**Have a question about this project?** Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Pick a username

Email Address

Password

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CVE-2022-43285: SEGV in njs_promise_reaction_job · Issue #533 · nginx/njs

Even if the security bug is not another Heartbleed, prepare like it might be, they note — it has potentially sprawling ramifications.

Organizations have five days to prepare for what the OpenSSL Project on Oct. 26 described as a "critical" vulnerability in versions 3.0 and above of the nearly ubiquitously used cryptographic library for encrypting communications on the Internet.

On Tuesday, Nov. 1, the project will release a new version of OpenSSL (version 3.0.7) that will patch an as-yet-undisclosed flaw in current versions of the technology. The characteristics of the vulnerability and ease with which it can be exploited will determine the speed with which organizations will need to address the issue.

**Potentially Huge Implications**

Major operating system vendors, software publishers, email providers, and technology companies that have integrated OpenSSL into their products and services will likely have updated versions of their technologies timed for release with the OpenSSL Project's disclosure of the flaw next Tuesday. But that will still leave potentially millions of others — including federal agencies, private companies, service providers, network device manufacturers, and countless website operators — with a looming deadline to find and fix the vulnerability before threat actors begin to exploit it.

If the new vulnerability turns out to be another Heartbleed bug — the last critical vulnerability to impact OpenSSL — organizations and indeed the entire industry are going to be under the gun to address the issue as quickly as possible.

The Heartbleed vulnerability (CVE-2014-0160), disclosed in 2014, basically gave attackers a way to eavesdrop on Internet communications, steal data from services and users, to impersonate services, and do all this with little trace of their ever having done any of it. The bug existed in OpenSSL versions from March 2012 onward and affected a dizzying range of technologies, including widely used Web servers such as Nginx, Apache, and IIS; organizations such as Google, Akamai, CloudFlare, and Facebook; email and chat servers; network appliances from companies such as Cisco; and VPNs.

The disclosure of the bug triggered a frenzy of remedial activity across the industry and sparked concerns of major compromises. As Synopsys' Heartbleed.com site noted, Apache and Nginx alone accounted for a market share of over 66% of active sites on the Internet at the time Heartbleed was disclosed.

There's no telling, until Tuesday at least, if the new flaw will be anything like Heartbleed. But given the almost critical-infrastructure-like use of OpenSSL for encryption across the Internet, organizations would do well not to underestimate the threat, security experts said this week.

**Security Orgs Should Brace for Impact**

"It is a bit difficult to speculate about the impact, but past experience has shown that OpenSSL doesn't use the label 'critical' lightly," says Johannes Ullrich, dean of research at the SANS Institute.

OpenSSL itself defines a critical flaw as one that enables significant disclosure of the contents of server memory and potential user details, vulnerabilities that can be exploited easily and remotely to compromise server private keys.

Version 3.0, the current release of OpenSSL, is used in many current operating systems, such as Ubuntu 22.04 LTS and MacOS Mavericks and Ventura, Ullrich notes. Organizations can expect to receive Linux patches quickly and likely at the same time as the OpenSSL bulletin on Tuesday. But organizations should get ready now, finding out which systems use OpenSSL 3.0, Ullrich says. "After Heartbleed, OpenSSL introduced these preannouncements of security patches," he says. "They are supposed to help organizations prepare. So, use this time to find out what will need patching."

Brian Fox, co-founder and CTO at Sonatype, says that by the time the OpenSSL Project discloses the bug Tuesday, organizations need to identify if they are using a vulnerable version anywhere in their technology portfolio, which applications are using it, and how long it would take for them to remediate the issue. 

"Potential reach is always the most consequential piece of any major flaw," Fox notes. "In this instance, the largest challenge with updating OpenSSL is that often this usage is embedded inside of other devices." In these instances, it can be hard to assess exposure without asking the upstream provider of the technology, he adds.

Anything that communicates with the Internet securely could potentially have OpenSSL built in to it. And it's not just software that can be affected but hardware as well. The advance notice that the OpenSSL Project provided should give organizations time to prepare. "Finding what pieces of software or devices is the first step. Organizations should do that now, and then patching or sourcing updates from the upstream vendors will follow," Fox says. "All you can do at the moment is inventory."

**An Entire Ecosystem Might Need to Update**

A lot will also depend on how vendors of products with vulnerable versions of OpenSSL embedded in them respond to the disclosure. The OpenSSL Project's release of the new version on Tuesday is only the first step. "An entire ecosystem of applications built with OpenSSL will also have to update their code, release their own updates, and organizations will need to apply them," says John Bambenek, principal threat hunter at Netenrich.

Ideally, organizations that have dealt with Heartbleed will have an idea of where their OpenSSL installs are and which of their vendor products will require an update as well. "This is why software bills of materials can be important," Bambenek says. "They can take this time to reach out and understand their suppliers and vendors plans for updates to make sure those updates are applied as well." One likely issue that organizations need to be prepared for is how to deal with end-of-life products for which updates are not available, he adds.

Mike Parkin, senior technical engineer at Vulcan Cyber, says that without evidence of exploit activity and associated indicators of compromise, it is best that organizations follow their normal change management process for when a known update is on the way. "On the security side, it's worth putting some additional focus on systems that might be affected if an exploit emerges before the new release drops," he advises.

There's not enough information in OpenSSL Project's announcement to say how much work will be involved in the upgrade, "but unless it requires updating certificates, the upgrade will probably be straightforward," Parkin predicts.

Also on Nov. 1, the OpenSSL project will release OpenSSL version 1.1.1s, which it described as a "bug-fix release." Version 1.1.1, which it replaces, is not susceptible to the CVE that is being fixed in 3.0, the project noted.

Prepare Now for Critical Flaw in OpenSSL, Security Experts Warn

Cross-site scripting vulnerability in BookStack versions prior to v22.09 allows a remote authenticated attacker to inject an arbitrary script.

Since BookStack can hold important information for users you should be aware of any potential security concerns. Read through the below to ensure you have secured your BookStack instance. Note, The below only relates to BookStack itself. The security of the server BookStack is hosted on is not instructed below but should be taken into account.

If you’d like to be notified of new potential security concerns you can sign-up to the BookStack security mailing list. For reporting security vulnerabilities, please see the “Security” section of the project readme on GitHub.

*   Initial Security Setup
*   Multi-Factor Authentication
*   Securing Images
*   Attachments
*   User Passwords
*   JavaScript in Page Content
*   Web Crawler Control
*   Secure Cookies
*   Host Iframe Control
*   Iframe Source Control
*   Failed Access Logging
*   Untrusted Server Side Requests
*   Content Security Policy (CSP)
*   MySQL SSL Connection
*   Using BookStack Content Externally

**Initial Security Setup**

1.  Ensure you change the password and email address for the initial admin@admin.com user.
2.  Ensure only the public folder is being served by your webserver. Serving files above this folder opens up a lot of code that does not need to be public. Triple check this if you have installed BookStack within the commonly used /var/www folder.
3.  Ensure the database user you’ve used for BookStack has limited permissions for only accessing the database used for BookStack data.
4.  Check that you’ve set the APP_URL option in your .env file so that system generated URLs cannot be manipulated.
5.  Within BookStack, go through the settings to ensure registration and public access settings are as you expect.
6.  Review the user roles in the settings area.
7.  Read the below to further understand the security for images & attachments.

**Multi-Factor Authentication**

Any user can enable multi-factor authentication (MFA) on their account. Upon login they would then need to use an extra proof of identity to gain access. BookStack currently supports the following mechanisms:

*   TOTP (Time-based One-Time Passwords)
    *   Labelled as “Mobile App” (Google/Microsoft Authenticator etc…).
    *   Uses a SHA1 algorithm internally (Greater algorithms have poor cross-app compatibility).
*   Backup Codes
    *   These are a list of 16 one-time-use codes.
    *   Users will be warned once they have less than 5 codes remaining.

Secrets and values for these options are stored encrypted within the database.

Where required, MFA can be forced upon users via their roles. This can be found via a “Requires Multi-Factor Authentication” checkbox seen when editing a role. If a user does not already have an MFA method configured, they will be forced to set one up upon next login.

**Securing Images**

By default, Images are stored in a way which is publicly accessible which ensures performance while using BookStack. Listed below are a few options for increasing image security.

**Alternative Storage Options**

Review our file upload storage options documentation for image storage options that add addition access or permission control to image requests.

**Complex Urls**

In the settings area of BookStack you can find the option ‘Enable higher security image uploads?’. Enabling this will add a 16 character random string to the name of image files to prevent easy guessing of URLs. This increases security without potential performance concerns.

**Prevent Directory Indexes**

It’s important to ensure you disable ‘directory indexes’ to prevent unknown users from being able to navigate their way through your images. Here’s the configuration for NGINX & Apache if your server allows directory indexes:

**NGINX**

    1
    2
    3
    4
    5
    

    # By default indexes are disabled on Nginx but if you have them enabled
    # add this to your BookStack server block
    location /uploads {
           autoindex off;
    }
    

**Apache**

    1
    2
    3
    4
    5
    

    # Add this to your Apache BookStack virtual host if Indexes are enabled.
    # If .htaccess file are enabled then the below should already be active.
    <Location "/uploads">
        Options -Indexes
    </Location>
    

You can test that indexes are disabled by attempting to navigate to <your_bookstack_url>/uploads/images in the browser after having uploaded at least one image. You should not see a list of files but instead a BookStack “Not Found” page.

**Attachments**

Attachments, if not using Amazon S3, are stored in the storage/uploads directory. By default, unlike images, these are stored behind the application authentication layer so access depends on permissions you have set up at a role level and page level.

If you are using Amazon S3 for file storage then access will depend on your S3 permission settings. Unlike images, BookStack will not automatically attempt to make uploaded attachments publically accessible.

**User Passwords**

User passwords, if not using an alternative authentication method, are stored in the database. These are hashed using the standard Laravel hashing methods which use the Bcrypt hashing algorithm.

**JavaScript in Page Content**

By default, JavaScript tags within page content is escaped when rendered. This can be turned off by setting ALLOW_CONTENT_SCRIPTS=true in your .env file. Note that even if you disable this escaping the WYSIWYG editor may still perform it’s own JavaScript escaping. This option will also alter the CSP rules set by BookStack.

_**This option disables some fundamental cross-site-scripting protections. Only use this option on secure instances, where only very trusted users can edit content**_

**Web Crawler Control**

The rules found in the /robots.txt file are automatically controlled via the “Allow public viewing?” setting. This can be overridden by setting ALLOW_ROBOTS=false or ALLOW_ROBOTS=true in your .env file. If you’d like to customise the rules this can be done via theme overrides.

**Secure Cookies**

BookStack uses cookies to track sessions, remember logins and for XSRF protection. When using HTTPS you may want to ensure that cookies are only sent back to the browser if the connection is over HTTPS. If you have set a https APP_URL option in your .env this will enabled automatically but it can also be forced on by setting SESSION_SECURE_COOKIE=true in your .env file.

**Host Iframe Control**

By default BookStack will only allow itself to be embedded within iframes on the same domain as you’re hosting on. This is done through a CSP: frame-ancestors header. You can add additional trusted hosts by setting a ALLOWED_IFRAME_HOSTS option in your .env file like the example below:

    1
    2
    3
    4
    5
    

    # Adding a single host
    ALLOWED_IFRAME_HOSTS="https://example.com"
    
    # Multiple hosts can be separated with a space
    ALLOWED_IFRAME_HOSTS="https://a.example.com https://b.example.com"
    

Note: when this option is used, all cookies will served with SameSite=None (info) set so that a user session can persist within the iframe.

**Iframe Source Control**

By default BookStack will only allow certain other hosts to be used as src values for embedded iframe/frame content within the application. This is done through a CSP: frame-src header. You can configure the list of trusted sources by setting a ALLOWED_IFRAME_SOURCES option in your .env file like the examples below:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    

    # Adding a single host
    ALLOWED_IFRAME_SOURCES="https://example.com"
    
    # Multiple hosts can be separated with a space
    ALLOWED_IFRAME_SOURCES="https://a.example.com https://b.example.com"
    
    # Allow all sources
    # This opens vulnerability risk and should only be done in secure & trusted environments.
    ALLOWED_IFRAME_SOURCES="*"
    

By default this option is configured as follows:

    1
    

    ALLOWED_IFRAME_SOURCES="https://*.draw.io https://*.youtube.com https://*.youtube-nocookie.com https://*.vimeo.com"
    

Note: The source of ‘self’ will always be automatically added to this CSP rule. In addition, the host used for the diagrams.net integration (If enabled) will be automatically appended to the lists of hosts.

**Failed Access Logging**

An option is available to log failed login events to a log file which is useful to identify users having trouble logging in, track malicious login attempts or to use with tools such as Fail2Ban. This works with login attempts using the default email & password login mechanism or attempts via LDAP login. Failed attempts are **not logged** for “one-click” social or SAML2 options.

To enable this you simply need to define the LOG_FAILED_LOGIN_MESSAGE option in your .env file like so:

    1
    

    LOG_FAILED_LOGIN_MESSAGE="Failed login for %u"
    

The optional “%u” element of the message will be replaced with the username or email provided in the login attempt when the message is logged. By default messages will be logged via the php error_log function which, in most cases, will log to your webserver error log files.

**Untrusted Server Side Requests**

Some features, such as the PDF exporting, have the option to make http calls to external user-defined locations to do things such as load images or styles. This is disabled by default but can be enabled if desired. This is required for using WKHTMLtoPDF as your PDF export renderer. This should only be enabled in BookStack environments where BookStack users and viewers are fully trusted.

To enable untrusted server side requests, you need to define the ALLOW_UNTRUSTED_SERVER_FETCHING option in your .env file like so:

    1
    

    ALLOW_UNTRUSTED_SERVER_FETCHING=true
    

**Content Security Policy (CSP)**

BookStack serves responses with a CSP header to increase protection again malicious content. This is especially important in a system such as BookStack where users can create a variety of HTML content, especially so if you allow untrusted users to create content in your instance. The CSP rules set by BookStack are as follows:

*   frame-ancestors 'self'
    *   Restricts what websites can embed BookStack pages via iframes.
    *   See the “Host Iframe Control” section above for details on expanding this rule to other hosts.
*   frame-source 'self' https://*.diagrams.net https://*.draw.io https://*.youtube.com https://*.youtube-nocookie.com https://*.vimeo.com https://embed.diagrams.net
    *   Restricts what sources are allowed to load for frames/iframes.
    *   Can be configured via a ALLOWED_IFRAME_SOURCES .env option.
    *   May be different depending on other configuration set.
*   script-src http: https: 'nonce-abc123' 'strict-dynamic'
    *   Restricts what scripts can be ran on a BookStack-served page.
    *   Will not be set if the ALLOW_CONTENT_SCRIPTS .env option is active.
    *   The nonce value used is randomly generated upon each request. It is automatically applied to any “Custom HTML Head Content” scripts.
*   object-src 'self'
    *   Restricts which embeddable content can be loaded onto a BookStack-served page.
    *   Will not be set if the ALLOW_CONTENT_SCRIPTS .env option is active.
*   base-uri 'self'
    *   Restricts what <base> tags can be added to a BookStack-served page.

If needed you should be able to set additional CSP headers via your webserver. If there’s a clash with an existing BookStack CSP header then browsers will generally favour the most restrictive policy.

**MySQL SSL Connection**

If your BookStack database is not on the same host as your web server, you may want to ensure the connection is encrypted using SSL between these systems. Assuming SSL is configured correctly on your MySQL server, you can enable this by defining the MYSQL_ATTR_SSL_CA option in your .env file like so:

    1
    2
    3
    4
    5
    

    # Path to Certificate Authority (CA) certificate file for your MySQL instance.
    # When this option is used host name identity verification will be performed
    # which checks the hostname, used by the client, against names within the
    # certificate itself (Common Name or Subject Alternative Name).
    MYSQL_ATTR_SSL_CA="/path/to/ca.pem"
    

**Using BookStack Content Externally**

In some scenarios you may use BookStack user-provided content externally (Accessed via the database or API). Such content is not guaranteed to be safe so keep security in mind when dealing with such content. In some cases, the system will apply some filtering to content in an attempt to prevent certain vulnerabilities, but this is not assured to be a bullet-proof defence.

Within its own interfaces, unless disabled, BookStack makes use of Content Security Policy (CSP) rules to heavily negate cross-site scripting vulnerabilities from user content. If displaying user content externally, it’s advised you also use defences such as CSP or other techniques such as disabling of JavaScript entirely.

CVE-2022-40690: Security ·  BookStack

A vulnerability was found in Nginx and classified as problematic. This issue affects some unknown processing of the file ngx_resolver.c of the component IPv4 Off Handler. The manipulation leads to memory leak. The attack may be initiated remotely. It is recommended to apply a patch to fix this issue. The identifier VDB-211937 was assigned to this vulnerability.

Tag

#nginx