Search This Blog

Powered by Blogger.

Blog Archive

Labels

Showing posts with label Linux Vulnerability. Show all posts

New ARM 'TIKTAG' Attack Affects Google Chrome and Linux Systems

 

A newly identified speculative execution attack named "TIKTAG" exploits ARM's Memory Tagging Extension (MTE) to leak data with a success rate exceeding 95%, allowing hackers to circumvent this security feature.

This discovery was detailed in a paper by researchers from Samsung, Seoul National University, and the Georgia Institute of Technology. They demonstrated the attack on Google Chrome and the Linux kernel.

MTE, introduced in ARM v8.5-A architecture and subsequent versions, aims to detect and prevent memory corruption. It utilizes low-overhead tagging by assigning 4-bit tags to 16-byte memory chunks to ensure that the tag in the pointer matches the accessed memory region.

MTE operates in three modes: synchronous, asynchronous, and asymmetric, to balance security and performance.

The researchers identified two gadgets, TIKTAG-v1 and TIKTAG-v2, which leverage speculative execution to leak MTE memory tags efficiently. While leaking these tags doesn't directly reveal sensitive information such as passwords or encryption keys, it can potentially weaken MTE's defenses, making systems vulnerable to covert memory corruption attacks.

TIKTAG-v1 exploits CPU behaviors such as branch prediction and data prefetching to leak MTE tags, particularly affecting the Linux kernel functions involving speculative memory accesses, though kernel pointer manipulation is necessary.

The attack involves using system calls to trigger the speculative execution path and measuring cache states to infer memory tags.

TIKTAG-v2 exploits speculative execution's store-to-load forwarding, where a value stored to a memory address is immediately loaded from the same address. If the tags match, the value is forwarded, altering the cache state; if not, forwarding is blocked, leaving the cache state unchanged.

By probing the cache state post-speculative execution, attackers can deduce the tag check results.

The effectiveness of TIKTAG-v2 was demonstrated against the Google Chrome browser's V8 JavaScript engine, potentially exposing memory corruption vulnerabilities in the renderer process.

The researchers reported their findings to the affected parties between November and December 2023, receiving generally positive feedback but no immediate fixes. Their technical paper on arxiv.org suggests several mitigations:

1. Modify hardware design to prevent speculative execution from altering cache states based on tag check results.
2. Insert speculation barriers (e.g., sb or isb instructions) to block speculative execution of critical memory operations.
3. Add padding instructions to extend the execution window between branch instructions and memory accesses.
4. Enhance sandboxing mechanisms to strictly limit speculative memory access paths within safe memory regions.

ARM acknowledged the seriousness of the situation but did not view it as a compromise of the feature, noting that allocation tags are not intended to be secrets within the address space.

Chrome's security team recognized the issues but chose not to address the vulnerabilities, citing that the V8 sandbox is not designed to ensure the confidentiality of memory data and MTE tags. Additionally, Chrome does not currently enable MTE-based defenses by default, making it a lower priority for immediate fixes.

The MTE vulnerabilities in the Pixel 8 device were reported to the Android security team in April 2024 and were acknowledged as a hardware flaw qualifying for a bounty reward.

Inherent Vulnerability in Linux Puts Russian OS at Risk

 

The vulnerability found in all distributions of the Linux operating system also puts at risk Russian OS based on it, which are used in banks, enterprises, and government agencies. Developers of Russian OS on Linux have already begun to publish updates that close the security gap. But the problem may not be an isolated one, since few people have been engaged in comprehensive research of the Linux source code. 
The vulnerability, called PwnKit, was discovered by the American company Qualys. Experts pointed out that the breach allows attackers to easily obtain administrator rights. The vulnerability is present in the pkexec component. The researchers claim that the vulnerability is installed by default on all Linux distributions and has existed in the pkexec component (graphical interface) since its creation, that is, almost 13 years. 

Kaspersky Lab researcher Boris Larin confirmed that the vulnerability also affected some Russian Linux distributions. The Russian developer RED SOFT, which produces the Russian Red OS based on Linux, acknowledged that the system uses a potentially unsafe module, but noted that the company regularly tests the system and has already released an update. 

It should be noted that administrator rights give unlimited opportunities to attackers, and most likely, within a year, this vulnerability will become the main tool for attacking devices running Linux. "Banks, industrial enterprises, and the public sector can be targeted," said Alexey Malynev, head of the Jet Infosystem Incident Monitoring and Response Center. 

Exploits that allow exploiting the vulnerability appeared a few hours after the information about the problem appeared. Developers have already started releasing security updates to close the gap. 

The revealed vulnerability demonstrates one of the important shortcomings of open source systems. "It seems that it is available, and everyone can check it, but in fact, few people do it, so no one has noticed the vulnerability for years," noted Pavel Korostelev, head of the Security Code product promotion department. 

Dmitry Derzhavin, head of CPI development, emphasizes that modern operating systems are millions of lines of code. "It so happened that no one has looked into this particular line until now, and there is no excuse for this oversight."

Undetected malware attacks Linux systems

A new sophisticated, unique Linux malware dubbed HiddenWasp used in targeted attacks against victim’s who are already under attack or gone through a heavy reconnaissance.

The malware is highly sophisticated and went undetected; the malware is still active and has a zero detection rate. The malware adopted a massive amount of codes from publically available malware such as Mirai and the Azazel rootkit.

Unlike Windows malware, Linux malware authors won’t concentrate much with evasion techniques, as the trend of using Anti-Virus solutions in Linux machine is very less when compared to other platforms.

However, the Intezer report shows “malware with strong evasion techniques does exist for the Linux platform. There is also a high ratio of publicly available open-source malware that utilizes strong evasion techniques and can be easily adapted by attackers.” In the past, we saw many malware focussed on crypto-mining or DDoS activity, but the HiddenWasp is purely a targeted remote control attack.

The malware is composed of a user-mode rootkit, a trojan, and an initial deployment script. Researchers spotted the files went undetected in VirusTotal and the malware hosted in servers of a hosting company ThinkDream located in Hong Kong.

While analyzing scripts, Intezer spotted a user named ‘sftp’ and hardcodes, which can be used for initial compromise and also the scripts has variable to clear the older versions from the compromised systems.

The scripts also include variables to determine server architecture of the compromised system and download components from the malicious server based on the compromised server architecture. Once the components installed, the trojan will get executed on the system.

“Within this script, we were able to observe that the main implants were downloaded in the form of tarballs. As previously mentioned, each tarball contains the main trojan, the rootkit, and a deployment script for x86 and x86_64 builds accordingly.”

Everything you need to know about Bash Bug "ShellShock"


A new critical security vulnerability in the BASH shell, the command-line shell used in many Unix and Linux operating systems, leaves a large number of systems at security risk. The bug also affects Mac OS X.

CVE Number: CVE-2014-6271

Technical Details: 

Here is technical details of the vulnerability, posted by Florian Weimer in Seclists:

"Bash supports exporting not just shell variables, but also shell functions to other bash instances, via the process environment to (indirect) child processes.  Current bash versions use an environment variable named by the function name, and a function definition starting with “() {” in the variable value to propagate function definitions through the environment.

The vulnerability occurs because bash does not stop after processing the function definition; it continues to parse and execute shell commands following the function definition.  For example, an environment variable setting of

  VAR=() { ignored; }; /bin/id

will execute /bin/id when the environment is imported into the bash process. (The process is in a slightly undefined state at this point. The PATH variable may not have been set up yet, and bash could crash after executing /bin/id, but the damage has already happened at this point.) "

Proof of Concept:
env e='() { Ignored; }; echo Vulnerable' bash -c "echo Hello"

Running the above command in Linux Terminal prints "vulnerable" and "Hello".So what exactly is happening here.

The 'env' command used to either print a list of environment variables or run another utility in an altered environment without having to modify the currently existing environment.

Here, the utility is 'bash' that executes the 'echo hello' command - and the environment variable 'e' is imported into the 'bash' process.

The bash shell process the function definition "() { Ignored; };"and then executes the "echo vulnerable" command.

* You can use the above POC code to test whether your system is vulnerable or not.

Real world Attack Scenario:

CGI stores the HTTP headers in environment variables. Let's say the example.com is running a CGI application written in Bash script.

We can modify the HTTP headers such that it will exploit the shellshock vulnerability in the target server and executes our code.

POC:

curl -k http://example.com/cgi-bin/test -H "User-Agent: () { :;}; echo Hacked > /tmp/Hacked.txt"
Here, the curl is sending request to the target website with the User-Agent containing the exploit code.  This code will create a file "Hacked.txt" in the "/tmp" directory of the server.

Who should be worried?
An attacker needs to send a malicious environment variable to an application that interacting with the Internet and this application should have either written in Bash or execute bash script within the app. So, Normal Desktop users are likely not affected by this bug.

However, if you are admin of a website and running CGI app written in BASH or using Bash script, You should be worried.

Metasploit Module:

A Metasploit Module has been released that exploits a code injection in specially crafted environment variables in Bash, specifically targeting Apache mod_cgi scripts through the HTTP_USER_AGENT variable.

You can find the module here.

Malware:
Cyber Criminals are already started to exploit this vulnerability for the malicious purpose.  A malware(ELF format) named as 'Linux/Bash0day', found by @yinettesys.

"Cybercriminals exploit bash 0day to get the ELF malware into web servers. ELF scans routers IP and sends exploit busybox to hack routers and doing DDoS." Malware Must Die who analyzed the malware told EHN.

"If exploit busybox hits the target, they will try to gain shell /bin/sh & brute the default login/passwords commonly used by routers"


Strings contained in the Malware sample

At the time of writing, the detection ratio in Virustotal is 0/55.

You can find the malware sample and more details of the malware at KernelMode website.

Wormable:
Robert Graham of Errata Security says the bug is wormable.  He wrote a script that scans the Internet and finds the vulnerable machines. So far, he found nearly 3,000 vulnerable systems on port 80.

"Consequently, even though my light scan found only 3000 results, this thing is clearly wormable, and can easily worm past firewalls and infect lots of systems." Graham wrote in his blog post.

DHCP RCE Proof of Concept:
https://www.trustedsec.com/september-2014/shellshock-dhcp-rce-proof-concept/


ModSecurity Rules:
RedHat has posted several mod_security rules that helps to prevent the attack:

Request Header values:

SecRule REQUEST_HEADERS "^\(\) {" "phase:1,deny,id:1000000,t:urlDecode,status:400,log,msg:'CVE-2014-6271 - Bash Attack'"

SERVER_PROTOCOL values:

SecRule REQUEST_LINE "\(\) {" "phase:1,deny,id:1000001,status:400,log,msg:'CVE-2014-6271 - Bash Attack'"

GET/POST names:

SecRule ARGS_NAMES "^\(\) {" "phase:2,deny,id:1000002,t:urlDecode,t:urlDecodeUni,status:400,log,msg:'CVE-2014-6271 - Bash Attack'"

GET/POST values:

SecRule ARGS "^\(\) {" "phase:2,deny,id:1000003,t:urlDecode,t:urlDecodeUni,status:400,log,msg:'CVE-2014-6271 - Bash Attack'"

File names for uploads:

SecRule  FILES_NAMES "^\(\) {"  "phase:2,deny,id:1000004,t:urlDecode,t:urlDecodeUni,status:400,log,msg:'CVE-2014-6271  - Bash Attack'" 
Patch:
A Patch has been released which ensures that no code is allowed after the end of a Bash function.  If you try to run the exploit code after applying the patch, you will get the following error message:



Unfortunately, the patch is incomplete, it still can be bypassed.  There is a workaround here, but it is not advisable. "CVE-2014-7169" has been assigned for the incomplete fix.

If you think we missed any information, feel free to comment here, we will add it to the article.

---------------------------------

Additional details:
This details isn't for you if you already know how export functions,'env' commands work :

Bash Export function-definition feature: 



Defining a function in Bash script:

       hello(){ echo "Hello World";}

Calling function in Bash script:
   hello

Create a child bash process and call our user-defined function:
bash -c hello

It won't work, because the child bash process doesn't aware that there is user-defined function called "hello". So, what to do?! Let us add the 'hello' function to the environment variable with Export command:

export -f hello

This will export the 'hello' function to the child process.  Let's try to create the child bash process again:

bash -c hello

Now the function is called without a problem.


We can achieve the samething in a single line with 'env' command. Let me first explain what 'env' command does.



'env':


The 'env' command used to either print a list of environment variables or run another utility in an altered environment without having to modify the currently existing environment.

Let's try to print environment variables with bash(creating child process):

bash -c printenv



The above command will print environment variables. Using 'env' command, you can pass a temporary environment variables to the child process:

env e="hello" bash -c printenv


Now, If you check the printed environment variables, you can find the "e='hello" in the result :)

Function passing with env command:

env hello='() { echo Hello World;};' bash -c hello

Bug in GnuTLS allows hackers to run malicious code in Your Linux

Another major security vulnerability has been discovered in the popular cryptographic Library 'GnuTLS' that leaves Linux vulnerable to remote code execution.

GNUTLS is a free library implementing Secure Socket Layer(SSL), Transport Layer Security (TLS) and Datagram Transport Layer Security(DTLS) protocols which are used to offer secure communications.
 
"A flaw was found in the way GnuTLS parsed session ids from Server Hello packets of the TLS/SSL handshake." an entry posted on the Red Hat Bug Tracker reads.

Flaw: The read_server_hello function checks only whether the length of the Session ID does not exceed incoming packet size but it fails to ensure it doesn't exceed maximum length of Session ID.

A malicious server could exploit this vulnerability by sending a very long Session ID value and run a malicious code in "a connecting TLS/SSL client using GnuTLS".

In March, a different vulnerability was patched in GnuTLS Library that could have allowed attackers "to create a specially crafted certificate that could be accepted by GnuTLS as valid for a site chosen by the attacker"

I've updated my Linux, Did you?