Red Hat Enterprise Linux 9 (RHEL 9) is the latest version of Red Hat’s flagship operating system, released at the Red Hat Summit in May 2022. New capabilities added to RHEL 9 help simplify how organizations manage security and compliance when deploying new systems or managing existing infrastructure. This article takes a brief look at three of the new security features available in this release.

Red Hat Enterprise Linux 9 (RHEL 9) is the latest version of Red Hat’s flagship operating system, released at the Red Hat Summit in May 2022. New capabilities added to RHEL 9 help simplify how organizations manage security and compliance when deploying new systems or managing existing infrastructure. This article takes a brief look at three of the new security features available in this release.

**SSH root password login disabled by default**

The default superuser account in Unix- and Linux-based systems is "root". Because the username is always "root" and access rights are unlimited, this account is the most valuable target for hackers. Attackers use bots to scan for systems with exposed SSH ports, and when found, they attempt to use common usernames and brute-force passwords to gain entry. Of course, the impact of a successful exploit would be a lot lower if the compromised user has unprivileged access. The breach would then be contained and limited to one user only.

With RHEL 9, root user authentication with a password over SSH has been disabled by default. The OpenSSH default configuration only allows root logins via authentication methods such as public-key authentication, reducing the chance that attackers will gain access through brute-force password attacks. Instead of using the root password, developers can access remote development environments using SSH keys to log in.

**OpenSSL 3.0.1**

RHEL 9 provides OpenSSL packages in upstream version 3.0.1, which includes many improvements and bug fixes over the previous versions. Some notable improvements include the following.

Providers are collections of algorithms, and you can choose different providers for different applications. This allows application developers to make security decisions about their applications without worrying too much about the security of underlying cryptographic algorithms. OpenSSL currently includes the following providers: **base, default, fips, legacy** and **null**. By default, OpenSSL loads and activates the **default** provider, which includes commonly used algorithms. Developers can programmatically invoke any providers based on application requirements.

The IBM Z-platform supports "CP Assist For Cryptographic Functions (CPACF)" which delivers high-speed on-chip cryptography. OpenSSL now supports this via NIST SP800-90A\-compliant AES-based deterministic random bit generator (DRBG). This allows applications running on IBM Z-platform to use this higher speed and more secure random number generator.

Finally, support has been added for better certificate management via Certificate Management Protocol (CMP, RFC 4210), the Certificate Request Message Format (CRMF), and HTTP transfer (RFC 6712). CMP messages are self-contained with protection independent of transfer mechanism, therefore they support end-to-end security.

Built-in RHEL utilities have been recompiled to utilize OpenSSL 3. This allows users to take advantage of new security ciphers for encrypting and protecting information.

**Improved system-wide crypto-policies**

In RHEL 9, the system-wide cryptographic policies have been adjusted to provide up-to-date security defaults:

*   Disabled TLS 1.0, TLS 1.1, DTLS 1.0, RC4, CAMELLIA, DSA, 3DES, and FFDHE-1024 in all policies. 
    
*   Increased minimum RSA key size and minimum Diffie-Hellman parameter size in LEGACY.
    
*   With the exception of Hash-based Message Authentication Codes (HMACs), SHA-1 is disabled in TLS and SSH algorithms.
    

If needed, customers can enable some of the disabled algorithms by using custom policies or sub policies.

Apart from the above, RHEL 9 includes protection against hardware-level security vulnerabilities like Spectre and Meltdown, and the operating system can also help user-space processes create memory areas inaccessible to malicious code. 

Additionally, RHEL 9 provides readiness for Payment Card Industry Data Security Standard (PCI DSS), the Health Insurance Portability and Accountability Act (HIPAA) and other customer security requirements. Its integrity measurement architecture (IMA) digital hashes and signatures create a new way for users to detect rogue infrastructure modifications.

Learn more about these and other security enhancements included in RHEL 9.

Security features in Red Hat Enterprise Linux 9

Bronze Starlight’s use of multiple ransomware families and its victim-targeting suggest there’s more to the group’s activities than just financial gain, security vendor says.

A China-based advanced persistent threat (APT) actor, active since early 2021, appears to be using ransomware and double-extortion attacks as camouflage for systematic, government-sponsored cyberespionage and intellectual property theft.

In all of the attacks, the threat actor has used a malware loader called the HUI Loader — associated exclusively with China-backed groups — to load Cobalt Strike Beacon and then deploy ransomware on compromised hosts. Researchers at Secureworks who are tracking the group as “Bronze Starlight” say it’s a tactic they have not observed other threat actors use.

Secureworks also says it has identified organizations in multiple countries that the adversary appears to have compromised. The group’s US-based victims include a pharmaceutical company, a law firm, and a media company with offices in Hong Kong and China. Others include electronic component designers and manufacturers in Japan and Lithuania, a pharmaceutical company in Brazil, and the aerospace and defense division of an Indian conglomerate. Some three-quarters of Bronze Starlight’s victims so far are organizations that have typically been of interest to government-sponsored Chinese cyber-espionage groups.

**Cycling Through Ransomware Families**

Since it began operations in 2021, Bronze Starlight has used at least five different ransomware tools in its attacks: LockFile, AtomSilo, Rook, Night Sky, and Pandora. Secureworks’ analysis shows that the threat actor used a traditional ransomware model with LockFile, where it encrypted data on a victim network and demanded a ransom for the decryption key. But it switched to a double-extortion model with each of the other ransomware families. In these attacks Bronze Starlight attempted to extort victims by both encrypting their sensitive data and threatening to leak it publicly. Secureworks identified data belonging to at least 21 companies posted on leak sites associated with AtomSilo, Rook, Night Sky, and Pandora.

While Bronze Starlight appears on the surface to be financially motivated, its real mission appears to be cyberespionage and intellectual property theft in support of Chinese economic objectives, says Marc Burnard, senior consultant information security research at Secureworks. The US government last year formally accused China of using threat groups such as Bronze Starlight in state-sponsored cyber-espionage campaigns.

“The victimology, tooling, and rapid cycling through ransomware families suggest that Bronze Starlight’s intent may not be financial gain,” he says. Instead, it’s possible that the threat actor is using ransomware and double extortion as a cover to steal data from organizations of interest to China and destroy evidence of its activity.

Bronze Starlight has consistently targeted only a small number of victims over short periods of time with each ransomware family — something that threat groups don’t often do because of the overhead associated with developing and deploying new ransomware tools. In Bronze Starlight’s case, the threat actor appears to have employed the tactic to prevent drawing too much attention from security researchers, Secureworks said.

**The Chinese Connection**

Burnard says the threat actor’s use of the HUI Loader along with a relatively rare version of PlugX, a remote access Trojan linked exclusively to China-backed threat groups, is another sign that there’s more to Bronze Starlight than its ransomware activity might suggest.

“We believe the HUI Loader is a tool unique to Chinese state-sponsored threat groups,” Burnard says. It is not widely used, but where it has been used, the activity has been attributed to other likely Chinese threat group activity, such as one by a group dubbed Bronze Riverside that is focused on stealing IP from Japanese companies. 

“In terms of the use of the HUI Loader to load Cobalt Strike Beacons, this is one key characteristic of the Bronze Starlight activity that connects the broader campaign and five ransomware families together,” Burnard says.

Another sign that Bronze Starlight is more than just a ransomware operation involves a breach that Secureworks investigated earlier this year, where Bronze Starlight broke into a server at an organization that had previously already been compromised by another China-sponsored threat operation called Bronze University. In this incident, though, Bronze Starlight deployed the HUI Loader with Cobalt Strike Beacon on the compromised server, but it did not deploy any ransomware. 

“Again, this raises an interesting question around links between Bronze Starlight and state-sponsored threat groups in China,” Burnard says.

There’s also evidence that Bronze Starlight is learning from its intrusion activity and improving the HUI Loader’s capabilities, he adds. The version of the loader that the group used in its initial intrusions, for instance, were merely designed to load, decrypt, and execute a payload. But an updated version of the tool that Secureworks came across while responding to a January 2022 incident revealed several improvements. 

“The updated version comes with detection evasion techniques, such as disabling Windows Event Tracing for Windows \[ETW\] and Antimalware Scan Interface \[AMSI\] and Windows API hooking,” Burnard notes. “This indicates the HUI Loader is actively being developed and upgraded.”

Secureworks’ investigation shows that Bronze Starlight primarily compromises Internet-facing servers on victim organizations by exploiting known vulnerabilities. So as part of a multilayered approach to network security, network defenders should ensure that Internet-facing servers are patched in a timely manner, Burnard says. 

“While the focus is often on zero-day exploitation, we often see threat groups like Bronze Starlight exploit vulnerabilities that already have a patch available," he says.

Chinese APT Group Likely Using Ransomware Attacks as Cover for IP Theft

Johnson Controls will roll out the Tempered Networks platform across deployments of its OpenBlue AI-enabled platform.

**CORK, Ireland, June 23, 2022 —** Johnson Controls (NYSE: JCI), the global leader for smart, healthy, and sustainable buildings, today acquired zero trust cybersecurity provider – Tempered Networks, based in Seattle, Washington. Tempered Networks has created ‘Airwall’ technology, an advanced self-defense system for buildings that enables secure network access across diverse groups of endpoint devices, edge gateways, cloud platforms and service technicians. It represents a step-change in operational technology built on secure transmission pipelines to ensure buildings data exchanges and service actions can only take place between people and devices that are continuously authenticated.

The acquisition gives Johnson Controls the capability to provide zero trust security within the fabric of its OpenBlue secure communications stack, advancing its vision of enabling fully autonomous buildings that are inherently resilient to cyberattack.

**_How Airwall Works_**

Tempered Networks Airwall technology uses the Host Identity Protocol and a cloud-based policy orchestration platform to create new overlay networks built on encrypted and authenticated communication. The policy manager (a.k.a. the conductor) enforces configured digital policies that control connections within the cloaked overlay system. The default position for the policy manager is ‘zero trust’, i.e., only allowing connections between continuously authenticated and authorized entities. Once a communicating device authenticates itself correctly, an encrypted tunnel is created through which data flows. The advantages of this cybersecurity technique are as follows:

1\. The creation of an always-on and software-defined security perimeter protecting device-to-device, device-to-cloud and device-to-user interactions.

2\. Airwall achieves this by using Host Identity Protocol to create a cloaked and micro-segmented network which overlays a building’s existing network infrastructure, making the solution also highly cost-effective.

3\. A new level of authentication for connected building systems is created, allowing for greater system automation of functions such as heating and cooling, lighting, security and airflows.

“When it comes to buildings, we must create easily implementable cybersecurity defenses as we’re often dealing with critical infrastructure, including assets such as data centers and hospitals,” said Vijay Sankaran, vice president and chief technology officer, Johnson Controls. “Tempered Networks Airwall approach is purpose-built for our sector as it’s designed around principles of zero trust, securing device communications as data moves between devices and the cloud – so enabling remote building optimization in the most trusted way possible.”

**_Technology Integration_**

Tempered Networks Airwall technology is being integrated into Johnson Controls OpenBlue platform which is increasingly recognized as a leading smart building software platform with advanced AI-enabled building management capabilities\[1\]. OpenBlue provides a flexible computing approach for converging building technologies and making those technologies more insightful, powerful, and optimized through edge AI and through full machine learning in the cloud. The ultimate goal is to make all buildings smarter, healthier and more sustainable.

Financial terms of the transaction were not disclosed.

To learn more about Johnson Controls' approach to cybersecurity, please visit www.johnsoncontrols.com/cybersolutions.

See an explanation video for Tempered Networks Airwall technology here.

Johnson Controls Acquires Tempered Networks to Bring Zero Trust Cybersecurity to Connected Buildings

Insecure permissions in OneBlog v2.3.4 allows low-level administrators to reset the passwords of high-level administrators who hold greater privileges.

**Current description**

OneBlog v2.3.4 is vulnerable to insecure privileges. Low-level administrators can reset the passwords of high-level administrators who exceed their permissions.

**vulnerability recurrence**

First log in to the background using the low-privileged user admin/123456，This is a low-privileged user  

Click the modify password function, enter the old password and the new password, and then use burpsuite to crawl the packet

    POST /passport/updatePwd HTTP/1.1
    Host: localhost:8085
    User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:80.0) Gecko/20100101 Firefox/80.0
    Accept: */*
    Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
    Accept-Encoding: gzip, deflate
    Content-Type: application/x-www-form-urlencoded; charset=UTF-8
    X-Requested-With: XMLHttpRequest
    Content-Length: 66
    Origin: http://localhost:8085
    Connection: close
    Referer: http://localhost:8085/
    Cookie: session_user="93lkCfVDA258ElC3HuO7gUY4xGkEK1BFLktUlzaQ+c8="; Hm_lvt_1040d081eea13b44d84a4af639640d51=1654896251; pageno_cookie=1; SHIRO_SESSION_ID=47e409dd-e488-4e2f-8a68-42ae7cd2de9c; 
    
    id=2&password=123456&newPassword=1234567&newPasswordRepeat=1234567
    

Modify the id parameter to the id of another user, Because there is no verification here that the user id is consistent with the current user.

If the passwords of other users with the same permissions are the same as the password fields passed in, you can change the passwords of users with the same permissions horizontally. If the password of the highly privileged user is the same as the password field passed in, you can change the password of the high privileged account vertically. This feature does not verify that the password field is consistent with the password of the currently logged-in user, so password can be entered at will

Change id to 1. The user with an ID of 1 is the root user with the highest authority, because the password of the root user is the same as the 123456 passed in by password, so it is prompted that the modification was successful, and then you are required to log in again.

Log in to the root account again and find that the original password is no longer available.

Log in successfully with the new password

You can also break the brute force to crack the password field and traverse the id field to try to change other users' passwords in batches.

You can see that the passwords of users with id 5 and 6 have been modified successfully.

**Vulnerability analysis**

com.zyd.blog.controller.PassportController

Reset the password in the updatePwd method of the / updatePwd path

Follow the com.zyd.blog.business.service.impl#updatePwd ：

First, obtain the User object according to the user id passed by the front-end user. If the User is not null, determine whether the password field passed by the user is consistent with the user password corresponding to the id, and if so, reset the password.

So in fact, neither verifying whether the user id is the currently logged in user, nor verifying that the original password is the password of the current user, which eventually leads to ultra vires vulnerability.

CVE-2022-34012: There is a Insecure Permissions vulnerability exists in OneBlog v2.3.4 · Issue #I5CB2O · yadong.zhang/OneBlog - Gitee.com

A Spring Data MongoDB application is vulnerable to SpEL Injection when using @Query or @Aggregation-annotated query methods with SpEL expressions that contain query parameter placeholders for value binding if the input is not sanitized.

All Vulnerability Reports

**CVE-2022-22980: Spring Data MongoDB SpEL Expression injection vulnerability through annotated repository query methods**  
**Severity**

High

**Vendor**

Spring by VMware

**Description**

A Spring Data MongoDB application is vulnerable to SpEL Injection when using @Query or @Aggregation-annotated query methods with SpEL expressions that contain query parameter placeholders for value binding if the input is not sanitized.

Specifically, an application is vulnerable when all of the following are true:

*   A repository query method is annotated with @Query or @Aggregation
*   The annotated query or aggregation value/pipeline contains SpEL parts using the parameter placeholder syntax within the expression
*   The user supplied input is not sanitized by the application

An application is not vulnerable if any of the following is true:

*   The annotated repository query or aggregation method does not contain expressions
*   The annotated repository query or aggregation method does not use the parameter placeholder syntax within the expression
*   The user supplied input is sanitized by the application
*   The repository is configured to use a QueryMethodEvaluationContextProvider that limits SpEL usage

**Affected VMware Products and Versions**

Severity is high unless otherwise noted.

*   Spring Data MongoDB
    *   3.4.0
    *   3.3.0 to 3.3.4
    *   Older, unsupported versions are also affected

**Mitigation**

Users of affected versions should apply the following mitigation: 3.4.x users should upgrade to 3.4.1+. 3.3.x users should upgrade to 3.3.5+. No other steps are necessary. There are other mitigation steps for applications that cannot upgrade to the above versions.

Other mitigation steps:

*   Rewrite query or aggregation declarations to use parameter references (“\[0\]” instead of “?0“) within the expression
*   Sanitize parameters before calling the query method
*   Reconfigure the repository factory bean through a BeanPostProcessor with a limited QueryMethodEvaluationContextProvider

Releases that have fixed this issue include:

*   Spring Data MongoDB
    *   3.4.1+
    *   3.3.5+

**Credit**

This issue was identified and responsibly reported by Zewei Zhang from NSFOCUS TIANJI Lab.

**References**

*   https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H/E:P/RL:O/RC:C/CR:H/IR:H/AR:H/MAV:N/MAC:H/MPR:N/MUI:N/MS:C/MC:H/MI:H/MA:H&version=3.1

**History**

2022-06-20: Initial vulnerability report published.

CVE-2022-22980: CVE-2022-22980 | Security

Redis v7.0 was discovered to contain a memory leak via the component streamGetEdgeID.

**Conversation**

 

add a comment to \`container\` in \`quicklist.h\`.
Because \`PLAIN\` and \`PACKED\` are not as easy to understand as \`NONE\`
and \`LISTPACK\` and we don't have a detailed comment on it.

Co-authored-by: Oran Agra <oran@redislabs.com>

\`the redis object pointer was populated.\` -> \`the sds pointer was populated.\`
We don't populate the redis object pointer in this function.

Till now, on MacOS we only used to enable SO\_KEEPALIVE,
but we didn't set the interval which is configurable via the \`tcp-keepalive\` config.
This adds support for that on MacOS, to match what we already do on Linux.

update macros ZIPLIST\_ENTRY\_END i think the right definition is ((zl)+intrev32ifbe(ZIPLIST\_BYTES(zl))-ZIPLIST\_END\_SIZE)

 

…#10663)

When user uses the same input key for SDIFF as the first one, the result must be empty, so we don't need to process the elements to test.

This method is like the one done in zset‘s \`zsetChooseDiffAlgorithm\`

Co-authored-by: Oran Agra <oran@redislabs.com>

In general, our error handler make sure the error
object is always a table. In some rare cases (such
as OOM error), the error handler will not be called
and the error object will be a string. The PR expose
the error even if its a string and not a table.

Currently there is no way to test it but if it'll ever happen,
it is better to propagate this string upwards than just
generate a generic error without any specific info.

 

\* Module API doc script: Mark unreleased API functions

\* fix broken quotes in generate-module-api-doc.rb

Co-authored-by: Oran Agra <oran@redislabs.com>

)

this seems to have been an oversight. syncing the flags so that NOTIFY\_NEW is available to modules.
missing in redis#10512

 

also fixing already defined constants build warning while at it.

Co-authored-by: Oran Agra <oran@redislabs.com>

Fixed RM\_Scan() usage example: \`RedisModuleCursor\` -> \`RedisModuleScanCursor\`

…edis#10661)

If we want to support bits that can be overlapping, we need to make sure
that:
1. we don't use the same bit for two return values.
2. values should be sorted so that prefer ones (matching more
   bits) come first.

Unintentional change in redis#9644 (since RC1) meant that an empty \`--save ""\` config
from command line, wouldn't have clear any setting from the config file

Added tests to cover that, and improved test infra to take additional
command line args for redis-server

fix some typo in "t\_zset.c".
1. \`zzlisinlexrange\` the function name mentioned in the comment is misspelled.
2. fix typo in function name\`zarndmemberReplyWithListpack\` -> \`zrandmemberReplyWithListpack\`

Changed cursor's type from \`int\` to \`unsigned long\`
allows handling database or key with more than 2^31 elements

Set \`old\_li\` to NULL to avoid linking it again on error.
Before the fix, loading an already existing library will cause the existing library to be added again. This cause not harm other then wrong statistics. The statistics that are effected  by the issue are:
\* \`libraries\_count\` and \`functions\_count\` returned by \`function stats\` command
\* \`used\_memory\_functions\` returned on \`info memory\` command
\* \`functions.caches\` returned on \`memory stats\` command

…0683)

It used to returns slots as strings, like:
\`\`\`
redis> cluster shards
1) 1) "slots"
   2) 1) "10923"
      2) "16383"
\`\`\`

CLUSTER SHARDS docs and the top comment of redis#10293 says that it returns integers.
Note other commands like CLUSTER SLOTS, it returns slots as integers.
Use addReplyLongLong instead of addReplyBulkLongLong, now it returns slots as integers:
\`\`\`
redis> cluster shards
1) 1) "slots"
   2) 1) (integer) 10923
      2) (integer) 16383
\`\`\`

This is a small breaking change, introduced in 7.0.0 (7.0 RC3, redis#10293)

Fixes redis#10680

I suggest to use "\[fpclassify\](https://en.cppreference.com/w/cpp/numeric/math/fpclassify)" for float
comparison with zero, because of expression "value == 0" with value very close to zero can be
considered as true with some performance compiler optimizations.

Note: this code was introduced by 9d520a7 to accept zset scores that get ERANGE in conversion
due to precision loss near 0.
But with Intel compilers, ICC and ICX, where optimizations for 0 check are more aggressive, "==0" is
true for mentioned functions, however should not be. Behavior is seen starting from O2.
This leads to a failure in the ZSCAN test in scan.tcl

Fix redis#10552

We no longer piggyback getkeys\_proc to hold the RedisModuleCommand struct, when exists

Others:
Use \`doesCommandHaveKeys\` in \`RM\_GetCommandKeysWithFlags\` and \`getKeysSubcommandImpl\`.
It causes a very minor behavioral change in commands that don't have actual keys, but have a spec
with \`CMD\_KEY\_NOT\_KEY\`.
For example, before this command \`COMMAND GETKEYS SPUBLISH\` would return
\`Invalid arguments specified for command\` but not it returns \`The command has no key arguments\`

…t dirty counter to 0 if we enable save (redis#10691)

## FLUSHALL
We used to restore the dirty counter after \`rdbSave\` zeroed it if we enable save.
Otherwise FLUSHALL will not be replicated nor put into the AOF.

And then we do increment it again below.
Without that extra dirty++, when db was already empty, FLUSHALL
will not be replicated nor put into the AOF.

We now gonna replace all that dirty counter magic with a call
to forceCommandPropagation (REPL and AOF), instead of all the
messing around with the dirty counter.
Added tests to cover three part (dirty counter, REPL, AOF).

One benefit other than cleaner code is that the \`rdb\_changes\_since\_last\_save\` is correct in this case.

## FLUSHDB
FLUSHDB was not replicated nor put into the AOF when db was already empty.
Unlike DEL on a non-existing key, FLUSHDB always does something, and that's to call the module hook. 
So basically FLUSHDB is never a NOP, and thus it should always be propagated.
Not doing that, could mean that if a module does something in that hook, and wants to
avoid issues of that hook being missing on the replica if the db is empty, it'll need to do complicated things.

So now FLUSHDB add call forceCommandPropagation, we will always propagate FLUSHDB.
Always propagating FLUSHDB seems like a safe approach that shouldn't have any drawbacks (other than looking odd)

This was mentioned in redis#8972

## Test section:
We actually found it while solving a race condition in the BGSAVE test (other.tcl).
It was found in extra\_ci Daily Arm64 (test-libc-malloc).
\`\`\`
\[exception\]: Executing test client: ERR Background save already in progress.
ERR Background save already in progress
\`\`\`

It look like \`r flushdb\` trigger (schedule) a bgsave right after \`waitForBgsave r\` and before \`r save\`.
Changing flushdb to flushall, FLUSHALL will do a foreground save and then set the dirty counter to 0.

… spaces for MULTI\_ARG configs parsing. And allow options value to use the -- prefix (redis#10660)

## Take one bulk string with spaces for MULTI\_ARG configs parsing
Currently redis-server looks for arguments that start with \`--\`,
and anything in between them is considered arguments for the config.
like: \`src/redis-server --shutdown-on-sigint nosave force now --port 6380\`

MULTI\_ARG configs behave differently for CONFIG command, vs the command
line argument for redis-server.
i.e. CONFIG command takes one bulk string with spaces in it, while the
command line takes an argv array with multiple values.

In this PR, in config.c, if \`argc > 1\` we can take them as is,
and if the config is a \`MULTI\_ARG\` and \`argc == 1\`, we will split it by spaces.

So both of these will be the same:
\`\`\`
redis-server --shutdown-on-sigint nosave force now --shutdown-on-sigterm nosave force
redis-server --shutdown-on-sigint nosave "force now" --shutdown-on-sigterm nosave force
redis-server --shutdown-on-sigint nosave "force now" --shutdown-on-sigterm "nosave force"
\`\`\`

## Allow options value to use the \`--\` prefix
Currently it decides to switch to the next config, as soon as it sees \`--\`, 
even if there was not a single value provided yet to the last config,
this makes it impossible to define a config value that has \`--\` prefix in it.

For instance, if we want to set the logfile to \`--my--log--file\`,
like \`redis-server --logfile --my--log--file --loglevel verbose\`,
current code will handle that incorrectly.

In this PR, now we allow a config value that has \`--\` prefix in it.
\*\*But note that\*\* something like \`redis-server --some-config --config-value1 --config-value2 --loglevel debug\`
would not work, because if you want to pass a value to a config starting with \`--\`, it can only be a single value.
like: \`redis-server --some-config "--config-value1 --config-value2" --loglevel debug\`

An example (using \`--\` prefix config value):
\`\`\`
redis-server --logfile --my--log--file --loglevel verbose
redis-cli config get logfile loglevel
1) "loglevel"
2) "verbose"
3) "logfile"
4) "--my--log--file"
\`\`\`

### Potentially breaking change
\`redis-server --save --loglevel verbose\` used to work the same as \`redis-server --save "" --loglevel verbose\`
now, it'll error!

Before this commit, all source files including those that are not going
to be compiled were used. Some of these files are platform specific and
won't even pre-process on another platform. With GCC/Clang, that's not
an issue and they'll simply ignore them, but ICC aborts in this case.

This commit only attempts to generate Makefile.dep from the actual set
of C source files that will be compiled.

…G flag for volatile configurations. (redis#10713)

This fixes a possible regression in Redis 7.0.0, in which doing CONFIG SET
on a TLS config would not reload the configuration in case the new config is
the same file as before.

A volatile configuration is a configuration value which is a reference to the
configuration data and not the configuration data itself. In such a case Redis
doesn't know if the config data changed under the hood and can't assume a
change happens only when the config value changes. Therefore it needs to
be applied even when setting a config value to the same value as it was before.

The purpose of the test is to kill the child while it is running.
From the last two lines we can see the child exits before being killed.
\`\`\`
- Module fork started pid: 56998
\* <fork> fork child started
- Killing running module fork child: 56998
\* <fork> fork child exiting
signal-handler (1652267501) Received SIGUSR1 in child, exiting now.
\`\`\`

In this commit, we pass an argument to \`fork.create\` indicating how
long it should sleep. For the fork kill test, we use a longer time to
avoid the child exiting before being killed.

Other changes:
use wait\_for\_condition instead of hardcoded \`after 250\`.
Unify the test for failing fork with the one for killing it (save time)

…10645)

Updated the comments for:
info command
lmpopCommand and blmpopCommand
sinterGenericCommand 

Fix the missing "key" words in the srandmemberCommand function
For LPOS command, when rank is 0, prompt user that rank could be
positive number or negative number, and add a test for it

Alias was mistakenly forgotten when the sub commands introduced as json files.

since the sharded pubsub is different with pubsub, it's better to give users a hint to make it more clear.

This allows the module to know the usable size of an allocation
it made, rather than the consumed size.

…truct (redis#10697)

Move the client flags to a more cache friendly position within the client struct
we regain the lost 2% of CPU cycles since v6.2 ( from 630532.57 to 647449.80 ops/sec ).
These are due to higher rate of calls to getClientType due to changes in redis#9166 and redis#10020

…M check bug, and new RM\_Call checks. (redis#10786)

\* Fix broken protocol when redis can't persist to RDB (general commands, not
  modules), excessive newline. regression of redis#10372 (7.0 RC3)
\* Fix broken protocol when Redis can't persist to AOF (modules and
  scripts), missing newline.
\* Fix bug in OOM check of EVAL scripts called from RM\_Call.
  set the cached OOM state for scripts before executing module commands too,
  so that it can serve scripts that are executed by modules.
  i.e. in the past EVAL executed by RM\_Call could have either falsely
  fail or falsely succeeded because of a wrong cached OOM state flag.
\* Fix bugs with RM\_Yield:
  1. SHUTDOWN should only accept the NOSAVE mode
  2. Avoid eviction during yield command processing.
  3. Avoid processing master client commands while yielding from another client
\* Add new two more checks to RM\_Call script mode.
  1. READONLY You can't write against a read only replica
  2. MASTERDOWN Link with MASTER is down and \`replica-serve-stale-data\` is set to \`no\`
\* Add new RM\_Call flag to let redis automatically refuse \`deny-oom\` commands
  while over the memory limit. 
\* Add tests to cover various errors from Scripts, Modules, Modules
  calling scripts, and Modules calling commands in script mode.

Add tests:
\* Looks like the MISCONF error was completely uncovered by the tests,
  add tests for it, including from scripts, and modules
\* Add tests for NOREPLICAS from scripts
\* Add tests for the various errors in module RM\_Call, including RM\_Call that
  calls EVAL, and RM\_call in "eval mode". that includes:
  NOREPLICAS, READONLY, MASTERDOWN, MISCONF

The important part is that read-only scripts (not just EVAL\_RO
and FCALL\_RO, but also ones with \`no-writes\` executed by normal EVAL or
FCALL), will now be permitted to run during CLIENT PAUSE WRITE (unlike
before where only the \_RO commands would be processed).

Other than that, some errors like OOM, READONLY, MASTERDOWN are now
handled by processCommand, rather than the command itself affects the
error string (and even error code in some cases), and command stats.

Besides that, now the \`may-replicate\` commands, PFCOUNT and PUBLISH, will
be considered \`write\` commands in scripts and will be blocked in all
read-only scripts just like other write commands.
They'll also be blocked in EVAL\_RO (i.e. even for scripts without the
\`no-writes\` shebang flag.

This commit also hides the \`may\_replicate\` flag from the COMMAND command
output. this is a \*\*breaking change\*\*.

background about may\_replicate:
We don't want to expose a no-may-replicate flag or alike to scripts, since we
consider the may-replicate thing an internal concern of redis, that we may
some day get rid of.
In fact, the may-replicate flag was initially introduced to flag EVAL: since
we didn't know what it's gonna do ahead of execution, before function-flags
existed). PUBLISH and PFCOUNT, both of which because they have side effects
which may some day be fixed differently.

code changes:
The changes in eval.c are mostly code re-ordering:
- evalCalcFunctionName is extracted out of evalGenericCommand
- evalExtractShebangFlags is extracted luaCreateFunction
- evalGetCommandFlags is new code

Apparently, GCC 11.2.0 has a new fancy warning for misleading indentations.
It prints a warning when BRET(b) is on the same line as the loop.

 

…, and inserting comments around module and acl configs (redis#10761)

A regression from redis#10285 (redis 7.0).
CONFIG REWRITE would put lines with: \`include\`, \`rename-command\`,
\`user\`,  \`loadmodule\`, and any module specific config in a comment.

For ACL \`user\`, \`loadmodule\` and module specific configs would be
re-inserted at the end (instead of updating existing lines), so the only
implication is a messy config file full of comments.

But for \`rename-command\` and \`include\`, the implication would be that
they're now missing, so a server restart would lose them.

Co-authored-by: Oran Agra <oran@redislabs.com>

Skip the print on AOF\_NOT\_EXIST status.

 

Redis 7 adds some new alias config like \`hash-max-listpack-entries\` alias \`hash-max-ziplist-entries\`.

If a config file contains both real name and alias like this:
\`\`\`
hash-max-listpack-entries 20
hash-max-ziplist-entries 20
\`\`\`

after set \`hash-max-listpack-entries\` to 100 and \`config rewrite\`, the config file becomes to:
\`\`\`
hash-max-listpack-entries 100
hash-max-ziplist-entries 20
\`\`\`

we can see that the alias config is not modified, and users will get wrong config after restart.

6.0 and 6.2 doesn't have this bug, since they only have the \`slave\` word alias.

Co-authored-by: Oran Agra <oran@redislabs.com>

\* Update time independent string compare to use hash length

On line 4068, redis has a logical nodeIsSlave(myself) on the outer if layer,
which you can delete without having to repeat the decision

…and instantaneous\_output\_repl\_kbps. (redis#10810)

A supplement to redis#10062
Split \`instantaneous\_repl\_total\_kbps\` to \`instantaneous\_input\_repl\_kbps\` and \`instantaneous\_output\_repl\_kbps\`. 
## Work:
This PR:
- delete 1 info field:
    - \`instantaneous\_repl\_total\_kbps\`
- add 2 info fields:
    - \`instantaneous\_input\_repl\_kbps / instantaneous\_output\_repl\_kbps\`
## Result:
- master
\`\`\`
total\_net\_input\_bytes:26633673
total\_net\_output\_bytes:21716596
total\_net\_repl\_input\_bytes:0
total\_net\_repl\_output\_bytes:18433052
instantaneous\_input\_kbps:0.02
instantaneous\_output\_kbps:0.00
instantaneous\_input\_repl\_kbps:0.00
instantaneous\_output\_repl\_kbps:0.00
\`\`\`
- slave
\`\`\`
total\_net\_input\_bytes:18433212
total\_net\_output\_bytes:94790
total\_net\_repl\_input\_bytes:18433052
total\_net\_repl\_output\_bytes:0
instantaneous\_input\_kbps:0.00
instantaneous\_output\_kbps:0.05
instantaneous\_input\_repl\_kbps:0.00
instantaneous\_output\_repl\_kbps:0.00
\`\`\`

Trying to avoid people opening crash report issues about module crashes and ARM QEMU bugs.

Current documentation only states a single GET token is needed which is not true. Marking the command with multiple\_token.

Currently generate-command.help.rb dose not handle the
multiple\_token flag, handle this flag in this PR.
The format is the same as redis-cli rendering.
\`\`\`diff
- bitfield\_ro key GET encoding offset \[encoding offset ...\]
+ bitfield\_ro key GET encoding offset \[GET encoding offset ...\]
\`\`\`

Re run generate-command-code.py which was forget in redis#10820.
Also change the flag value from string to bool, like "true" to true

Correcting the introduction version of the command \`BITFIELD\_RO\`
Command added by commit: b3e4abf 

Add history info of the \`FULL\` modifier in \`XINFO STREAM\`
Modifier was added by commit: 1e2aee3

(Includes output from \`./utils/generate-command-code.py\`)

Currently, we only increment stat\_rdb\_saves in rdbSaveBackground,
we should also increment it in the SAVE command.

We concluded there's no need to increment when:
1. saving a base file for an AOF
2. when saving an empty rdb file to delete an old one
3. when saving to sockets (not creating a persistence / snapshot file)

The stat counter was introduced in redis#10178

\* fix a wrong comment in startSaving

This change fixes failing \`integration/logging.tcl\` test in Gentoo with
musl libc, where \`ldd\` returns
\`\`\`
libc.so => /lib/ld-musl-x86\_64.so.1 (0x7f9d5f171000)
\`\`\`
unlike Alpine's
\`\`\`
libc.musl-x86\_64.so.1 => /lib/ld-musl-x86\_64.so.1 (0x7f82cfa16000)
\`\`\`
The solution is to extend matching pattern introduced in redis#8532.

 oranagra changed the base branch from unstable to 7.0

Jun 8, 2022

CVE-2022-33105: Release 7.0.1 by oranagra · Pull Request #10829 · redis/redis

An issue was discovered in SaltStack Salt in versions before 3002.9, 3003.5, 3004.2. PAM auth fails to reject locked accounts, which allows a previously authorized user whose account is locked still run Salt commands when their account is locked. This affects both local shell accounts with an active session and salt-api users that authenticate via PAM eauth.

CVE-2022-22967: Salt Project Package Repo

The Bosch Ethernet switch PRA-ES8P2S with software version 1.01.05 runs its web server with root privilege. In combination with CVE-2022-23534 this could give an attacker root access to the switch.

CVE-2022-32535: Multiple Vulnerabilities PRA-ES8P2S Ethernet-Switch

The concept might make us sharp and realistic, but it's not enough on its own.

**The Rise of the Presumption of Compromise**

In cybersecurity, we often say that "prevention is ideal, but detection is a must." But why do we say that? Shouldn't both prevention and detection be musts in a layered, defense-in-depth security approach? Well, this saying is rooted in a realistic view of reality, where we, as cyber-defense professionals, have come to accept that it's almost impossible to prevent the bad guys from breaking into connected systems. The choices are either total isolation (which, in some cases, can be circumvented) or risking a breach of the system. This notion of failing prevention has become a linchpin in our modern defense strategy and has become known as a "presumption of compromise." That is, assume that you already have been breached and focus on never-ending detection and eradication of the badness lurking in your systems.

Since we failed with prevention, we turned to detection. To paraphrase Churchill: No one pretends that detection is perfect or all-wise. Indeed, it has been said that detection is the worst form of defense except for all those other forms that have been tried.

**The Inevitable Fall of Presumption of Compromise**

Nevertheless, the current form of presumption of compromise — which focuses on rapid detection — is intended to fail because its contemporary version serves merely as a tactical tool rather than as a strategical framework. It tells you what not to rely on but doesn't tell you how to truly solve the problem. Instead of providing a solution, presumption of compromise merely kicks the can down the road.

In a recent thought-provoking experiment, security researchers from Splunk tried to determine the speed of encryption of modern ransomware malware families. They selected 10 ransomware families and measured the time it took each to encrypt 100,000 files on a victim's system. The results were astonishing. It took 45 minutes on average, with the slowest ransomware (Babuk) able to encrypt the files within 3.5 hours, while the fastest ransomware (Lockbit) achieved this goal within only 4 minutes (!).

Other recent research, which analyzed ransomware attacks, concluded that "the average duration of an enterprise ransomware attack reduced 94.34% between 2019 and 2021."

An additional parameter to consider in this context is breakout time, which measures how much time it takes for an adversary to hop from an initially compromised system on to the next. According to CrowdStrike, the average breakout time in 2021 is 1.5 hours. In 2018, it was almost 2 hours.

Unfortunately, these measurements provide a dismal forecast for our near future. The attackers are getting faster, and the ever-shrinking detection window is under a constant pressure.

**Automation Arms Race**

To detect faster, defenders turn to automation — sometimes by using static signatures and detection rules, and sometimes with the help of machine learning. Unfortunately, automation is not the monopoly of the good guys, and attackers use it as well. Being able to inflict damage faster and with fewer human personnel is serving the attackers' business models well, so the incentive to automate attacks has never been stronger.

Once both sides — the attack and the defense — increasingly turn to automation, we end up in a spiraling automation arms race. The defenders have had a head start in this race, spending the last several years developing and deploying AI-based solutions. Nevertheless, it's frightening to think about the consequences of the mass adoption of such technologies by the attackers, which continues to narrow the detection window.

**The Rebirth of the Presumption of Compromise**

The inevitable shrinkage of the detection window forces us to rethink its foundation. In the long term, it appears that detection alone is no longer a viable defense strategy. Instead, I believe that the focus of defensive strategy will be passed on to resilience — being able to recover quickly from an incident, with automation and volatile computerized systems that can be brought up and down instantly playing a pivotal role.

Make no mistake: A presumption of compromise is a good idea after all. It keeps us sharp and realistic. Nonetheless, its current detection-oriented manifestation looks like a losing strategy over the long term. Instead, we should start focusing on resilient, self-recoverable, and instantly rebuildable systems. Such recoverability will lay out the missing brick of the solution: protection, detection, and resilience. Together, they have the power to form the holy trinity of a truly sustainable defense-in-depth strategy.

The Rise, Fall, and Rebirth of the Presumption of Compromise

The leak site essential to the operation of Conti ransomware has disappeared, but everything may not be as it appears.
The post Conti ransomware group’s pulse stops, but did it fake its own death? appeared first on Malwarebytes Labs.

The dark web leak site used by the notorious Conti ransomware gang has disappeared, along with the chat function it used to negotiate ransoms with victims. For as long as this infrastructure is down the group is unable to operate and a significent threat is removed from the pantheon of ransomware threats.

The Conti leak site is down (June 22, 2022)

Ransomware gangs like Conti use the threat of leaking stolen data on their dark web sites to extort enormous ransoms from their victims, making the sites a vital cog in the ransomware machine.

While the cause of the site’s disappearance isn’t known for sure, and criminal dark web sites are notoriously flaky, there is good reason to suspect that Conti has gone permanently.

However, while anything that stops Conti from terrorising businesses, schools, and hospitals is welcome, the disappearance of its leak site is unlikely to make potential ransomware victims any safer, sadly.

As we explained in our May ransomware review, recent research by Advintel suggests that Conti has spent the last few months executing a bizarre plan to fake its own death. If that is what’s happened, then the gang’s members have simply dispersed to other ransomware “brands” that are either operated by the Conti gang or affiliated to it.

**Conti—as bad as they come**

The gang behind Conti ransomware (called WizardSpider, although rarely referred to by that name) is believed to be based in Russia, and first appeared in 2020. The FBI recently called it “the costliest strain of ransomware ever documented,” and the US Department of State is offering a reward of up to $10 million for “information leading to the identification and/or location of any individual(s) who hold a key leadership position in the Conti ransomware variant transnational organized crime group.”

Conti has been used in a number of high profile attacks, including a devastating assault on Ireland’s Health Service executive on May 14, 2021. The attack disrupted healthcare in Ireland for months and the recovery effort could end up costing the country more than $100 million.

The real cost of the attack was measured in human suffering though. Speaking to Malwarebytes Labs, a doctor in one of the affected hospitals described how a 21st-century healthcare system deprived of it’s computers is brought to its knees. The attack caused enormous unnecessary suffering for both patients and healthcare professionals, and triggered hundreds of thousands of appointments to be cancelled.

The doctor’s brutal assessment of the Conti gang? “I think they lost their humanity.”

**Faking its own death**

According to Advintel, the Conti gang sealed its fate in February when it published a message in support of Russia’s invasion of Ukraine, declaring its “full support of Russian government.” By aligning itself to the Russian state it had made itself the subject of sanctions. Victims were not prepared to run the risk that their ransom payments might be treated as sanctions violations and Conti’s income dried up.

Ransomware gangs often react to trouble by going dark, or with ham-fisted attempts to pretend they’ve retired. These retirements are often quickly followed by the sudden appearance of a brand new ransomware gang that is obviously just the old gang working under a new name.

Advintel’s research suggested that Conti was aware of this pattern and determined to try something different. Instead of disappearing and then popping up a week later under a new name, the group created and operated new brands—Advintel names KaraKurt, BlackByte, and BlackBasta as examples—before retiring the Conti name, to make the transition less obvious. In addition to creating these new brands, it also dispersed parts of its workforce into existing gangs it had a relationship with, such as Hive and ALPHV.

To complete the deception, it maintained a skeleton crew that carried out extremely noisy, headline-grabbing attacks on Cost Rica, and continued to operate the leak site until the last moment.

Malwarebytes Threat Intelligence was able to independently confirm that Conti sent an internal announcement about its retirement to affiliates at the end of May, and that its internal chat servers stopped working around the same time.

The site had been inactive for 28 days before it disappeared, with the last new leak appearing on May 25. As our May ransomware report revealed, despite the noise it generated from its attacks on Costa Rica, Conti’s activity was significantly depressed in May, while the activity of gangs with alleged links to Conti increased, driven largely by the rise of BlackBasta.

Known ransomware attacks in May 2022

Tag

#mac