An issue was discovered in the C AMQP client library (aka rabbitmq-c) through 0.13.0 for RabbitMQ. Credentials can only be entered on the command line (e.g., for amqp-publish or amqp-consume) and are thus visible to local attackers by listing a process and its arguments.

Hi,  
the command line tools like amqp-publish and amqp-consume are insecure, since the username/password can be given as a command line parameter either with --password= or as part of the URL given with --url.

Passwords given as command line parameters are insecure, since they can be seen in the process list.

It should have alternative options to have the password read from a given file or pipe.

CVE-2023-35789: insecure password option · Issue #575 · alanxz/rabbitmq-c

A stack-based buffer overflow issue was found in ImageMagick's coders/tiff.c. This flaw allows an attacker to trick the user into opening a specially crafted malicious tiff file, causing an application to crash, resulting in a denial of service.

Expand Up

@@ -2001,6 +2001,11 @@ static Image \*ReadTIFFImage(const ImageInfo \*image\_info,

if (HeapOverflowSanityCheck(rows,sizeof(\*tile\_pixels)) != MagickFalse)

ThrowTIFFException(ResourceLimitError,"MemoryAllocationFailed");

extent=MagickMax(rows\*TIFFTileRowSize(tiff),TIFFTileSize(tiff));

#if defined(TIFF\_VERSION\_BIG)

extent+=image->columns\*sizeof(uint64);

#else

extent+=image->columns\*sizeof(uint32);

#endif

tile\_pixels=(unsigned char \*) AcquireQuantumMemory(extent,

sizeof(\*tile\_pixels));

if (tile\_pixels == (unsigned char \*) NULL)

Expand Down

CVE-2023-3195: fix stack overflow when parsing malicious tiff image · ImageMagick/ImageMagick@f620340

A heap use after free issue was discovered in ImageMagick's ReplaceXmpValue() function in MagickCore/profile.c. An attacker could trick user to open a specially crafted file to convert, triggering an heap-use-after-free write error, allowing an application to crash, resulting in a denial of service.

'2214149?cve=title' is not a valid bug number nor an alias to a bug.

Please press **Back** and try again.

CVE-2023-34475: Invalid Bug ID

A heap-based buffer overflow issue was discovered in ImageMagick's ReadTIM2ImageData() function in coders/tim2.c. A local attacker could trick the user in opening specially crafted file, triggering an out-of-bounds read error, allowing an application to crash, resulting in a denial of service.

'2214148?cve=title' is not a valid bug number nor an alias to a bug.

Please press **Back** and try again.

CVE-2023-34474: Invalid Bug ID

A double free or use after free could occur after SSL_clear in OpenBSD 7.2 before errata 026 and 7.3 before errata 004, and in LibreSSL before 3.6.3 and 3.7.x before 3.7.3. NOTE: OpenSSL is not affected.

We have released LibreSSL 3.6.3, which will be arriving in the LibreSSL directory of your local OpenBSD mirror soon. It includes the following fixes: \* Bug fix - Hostflags in the verify parameters would not propagate from an SSL\_CTX to newly created SSL. \* Reliability fix - A double free or use after free could occur after SSL\_clear(3). The LibreSSL project continues improvement of the codebase to reflect modern, safe programming practices. We welcome feedback and improvements from the broader community. Thanks to all of the contributors who helped make this release possible.

CVE-2023-35784

An out of bounds (OOB) memory access flaw was found in the Linux kernel in relay_file_read_start_pos in kernel/relay.c in the relayfs. This flaw could allow a local attacker to crash the system or leak kernel internal information.

\* **\[PATCH\] relayfs: fix out-of-bounds access in relay\_file\_read**
**@ 2023-04-19  4:02 zhangzhengming**
  2023-04-19 21:03 \` Andrew Morton
  0 siblings, 1 reply; 4+ messages in thread
From: zhangzhengming @ 2023-04-19  4:02 UTC (permalink / raw)
  To: akpm, surenb, wuchi.zero, Ilia.Gavrilov, xu.panda, colin.i.king
  Cc: linux-kernel, zhou.kete, Zhang Zhengming

From: Zhang Zhengming <zhang.zhengming@h3c.com>

There is a crash in relay\_file\_read, as the var from 
point to the end of last subbuf.
The oops looks something like:
pc : \_\_arch\_copy\_to\_user+0x180/0x310
lr : relay\_file\_read+0x20c/0x2c8
Call trace:
 \_\_arch\_copy\_to\_user+0x180/0x310
 full\_proxy\_read+0x68/0x98
 vfs\_read+0xb0/0x1d0
 ksys\_read+0x6c/0xf0
 \_\_arm64\_sys\_read+0x20/0x28
 el0\_svc\_common.constprop.3+0x84/0x108
 do\_el0\_svc+0x74/0x90
 el0\_svc+0x1c/0x28
 el0\_sync\_handler+0x88/0xb0
 el0\_sync+0x148/0x180

We get the condition by analyzing the vmcore:
1). The last produced byte and last consumed byte
    both at the end of the last subbuf
2). A softirq who will call function(e.g \_\_blk\_add\_trace)
    to write relay buffer occurs when an program calling
    function relay\_file\_read\_avail.
        relay\_file\_read
                relay\_file\_read\_avail
                        relay\_file\_read\_consume(buf, 0, 0);
                        //interrupted by softirq who will write subbuf
                        ....
                        return 1;
                //read\_start point to the end of the last subbuf
                read\_start = relay\_file\_read\_start\_pos
                //avail is equal to subsize
                avail = relay\_file\_read\_subbuf\_avail
                //from  points to an invalid memory address             
                from = buf->start + read\_start
                //system is crashed
                copy\_to\_user(buffer, from, avail)

Signed-off-by: Zhang Zhengming <zhang.zhengming@h3c.com>
Reviewed-by: Zhao Lei <zhao\_lei1@hoperun.com>
Reviewed-by: Zhou Kete <zhou.kete@h3c.com>
---
 kernel/relay.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/kernel/relay.c b/kernel/relay.c
index 9aa70ae..a80fa01 100644
--- a/kernel/relay.c
+++ b/kernel/relay.c
@@ -989,7 +989,8 @@ static size\_t relay\_file\_read\_start\_pos(struct rchan\_buf \*buf)
 	size\_t subbuf\_size = buf->chan->subbuf\_size;
 	size\_t n\_subbufs = buf->chan->n\_subbufs;
 	size\_t consumed = buf->subbufs\_consumed % n\_subbufs;
\-	size\_t read\_pos = consumed \* subbuf\_size + buf->bytes\_consumed;
+	size\_t read\_pos = (consumed \* subbuf\_size + buf->bytes\_consumed)
+			% (n\_subbufs \* subbuf\_size);
 
 	read\_subbuf = read\_pos / subbuf\_size;
 	padding = buf->padding\[read\_subbuf\];
-- 
2.17.1

^ permalink raw reply related	\[**flat**|nested\] 4+ messages in thread

\* **Re: \[PATCH\] relayfs: fix out-of-bounds access in relay\_file\_read**
  2023-04-19  4:02 \[PATCH\] relayfs: fix out-of-bounds access in relay\_file\_read zhangzhengming
**@ 2023-04-19 21:03 \` Andrew Morton**
  2023-04-19 21:07   \` Jens Axboe
  2023-04-23  8:28   \` Pengcheng Yang
  0 siblings, 2 replies; 4+ messages in thread
From: Andrew Morton @ 2023-04-19 21:03 UTC (permalink / raw)
  To: zhangzhengming
  Cc: surenb, wuchi.zero, Ilia.Gavrilov, xu.panda, colin.i.king,
	linux-kernel, zhou.kete, Pengcheng Yang, Jens Axboe

On Wed, 19 Apr 2023 12:02:03 +0800 zhangzhengming <zhang.zhengming@h3c.com> wrote:

\> From: Zhang Zhengming <zhang.zhengming@h3c.com>
> 
> There is a crash in relay\_file\_read, as the var from 
> point to the end of last subbuf.
> The oops looks something like:
> pc : \_\_arch\_copy\_to\_user+0x180/0x310
> lr : relay\_file\_read+0x20c/0x2c8
> Call trace:
>  \_\_arch\_copy\_to\_user+0x180/0x310
>  full\_proxy\_read+0x68/0x98
>  vfs\_read+0xb0/0x1d0
>  ksys\_read+0x6c/0xf0
>  \_\_arm64\_sys\_read+0x20/0x28
>  el0\_svc\_common.constprop.3+0x84/0x108
>  do\_el0\_svc+0x74/0x90
>  el0\_svc+0x1c/0x28
>  el0\_sync\_handler+0x88/0xb0
>  el0\_sync+0x148/0x180
> 
> We get the condition by analyzing the vmcore:
> 1). The last produced byte and last consumed byte
>     both at the end of the last subbuf
> 2). A softirq who will call function(e.g \_\_blk\_add\_trace)
>     to write relay buffer occurs when an program calling
>     function relay\_file\_read\_avail.
>         relay\_file\_read
>                 relay\_file\_read\_avail
>                         relay\_file\_read\_consume(buf, 0, 0);
>                         //interrupted by softirq who will write subbuf
>                         ....
>                         return 1;
>                 //read\_start point to the end of the last subbuf
>                 read\_start = relay\_file\_read\_start\_pos
>                 //avail is equal to subsize
>                 avail = relay\_file\_read\_subbuf\_avail
>                 //from  points to an invalid memory address             
>                 from = buf->start + read\_start
>                 //system is crashed
>                 copy\_to\_user(buffer, from, avail)
Thanks.  Hopefully Pengcheng Yang and Jens Axboe can comment.

\> --- a/kernel/relay.c
> +++ b/kernel/relay.c
> @@ -989,7 +989,8 @@ static size\_t relay\_file\_read\_start\_pos(struct rchan\_buf \*buf)
>  	size\_t subbuf\_size = buf->chan->subbuf\_size;
>  	size\_t n\_subbufs = buf->chan->n\_subbufs;
>  	size\_t consumed = buf->subbufs\_consumed % n\_subbufs;
> -	size\_t read\_pos = consumed \* subbuf\_size + buf->bytes\_consumed;
> +	size\_t read\_pos = (consumed \* subbuf\_size + buf->bytes\_consumed)
> +			% (n\_subbufs \* subbuf\_size);
>  
>  	read\_subbuf = read\_pos / subbuf\_size;
>  	padding = buf->padding\[read\_subbuf\];
I'm thinking we should backport this into earlier kernels and that the
commit we're fixing is

Fixes: 341a7213e5c1 ("kernel/relay.c: fix read\_pos error when multiple readers")

^ permalink raw reply	\[**flat**|nested\] 4+ messages in thread

\* **Re: \[PATCH\] relayfs: fix out-of-bounds access in relay\_file\_read**
  2023-04-19 21:03 \` Andrew Morton
**@ 2023-04-19 21:07   \` Jens Axboe**
  2023-04-23  8:28   \` Pengcheng Yang
  1 sibling, 0 replies; 4+ messages in thread
From: Jens Axboe @ 2023-04-19 21:07 UTC (permalink / raw)
  To: Andrew Morton, zhangzhengming
  Cc: surenb, wuchi.zero, Ilia.Gavrilov, xu.panda, colin.i.king,
	linux-kernel, zhou.kete, Pengcheng Yang

On 4/19/23 3:03?PM, Andrew Morton wrote:
\> On Wed, 19 Apr 2023 12:02:03 +0800 zhangzhengming <zhang.zhengming@h3c.com> wrote:
> 
>> From: Zhang Zhengming <zhang.zhengming@h3c.com>
>>
>> There is a crash in relay\_file\_read, as the var from 
>> point to the end of last subbuf.
>> The oops looks something like:
>> pc : \_\_arch\_copy\_to\_user+0x180/0x310
>> lr : relay\_file\_read+0x20c/0x2c8
>> Call trace:
>>  \_\_arch\_copy\_to\_user+0x180/0x310
>>  full\_proxy\_read+0x68/0x98
>>  vfs\_read+0xb0/0x1d0
>>  ksys\_read+0x6c/0xf0
>>  \_\_arm64\_sys\_read+0x20/0x28
>>  el0\_svc\_common.constprop.3+0x84/0x108
>>  do\_el0\_svc+0x74/0x90
>>  el0\_svc+0x1c/0x28
>>  el0\_sync\_handler+0x88/0xb0
>>  el0\_sync+0x148/0x180
>>
>> We get the condition by analyzing the vmcore:
>> 1). The last produced byte and last consumed byte
>>     both at the end of the last subbuf
>> 2). A softirq who will call function(e.g \_\_blk\_add\_trace)
>>     to write relay buffer occurs when an program calling
>>     function relay\_file\_read\_avail.
>>         relay\_file\_read
>>                 relay\_file\_read\_avail
>>                         relay\_file\_read\_consume(buf, 0, 0);
>>                         //interrupted by softirq who will write subbuf
>>                         ....
>>                         return 1;
>>                 //read\_start point to the end of the last subbuf
>>                 read\_start = relay\_file\_read\_start\_pos
>>                 //avail is equal to subsize
>>                 avail = relay\_file\_read\_subbuf\_avail
>>                 //from  points to an invalid memory address             
>>                 from = buf->start + read\_start
>>                 //system is crashed
>>                 copy\_to\_user(buffer, from, avail)
> 
> Thanks.  Hopefully Pengcheng Yang and Jens Axboe can comment.
Patch looks good to me, but that doesn't necessarily say much. I never
did much relayfs hacking, and the bits I did was probably almost 20
years ago at this point when I wrote blktrace...

-- 
Jens Axboe

^ permalink raw reply	\[**flat**|nested\] 4+ messages in thread

\* **Re: \[PATCH\] relayfs: fix out-of-bounds access in relay\_file\_read**
  2023-04-19 21:03 \` Andrew Morton
  2023-04-19 21:07   \` Jens Axboe
**@ 2023-04-23  8:28   \` Pengcheng Yang**
  1 sibling, 0 replies; 4+ messages in thread
From: Pengcheng Yang @ 2023-04-23  8:28 UTC (permalink / raw)
  To: akpm
  Cc: Ilia.Gavrilov, axboe, colin.i.king, linux-kernel, surenb,
	wuchi.zero, xu.panda, yangpc, zhang.zhengming, zhou.kete,
	dwilder

On April 20, 2023 5:04 AM, Andrew Morton wrote:
\> On Wed, 19 Apr 2023 12:02:03 +0800 zhangzhengming <zhang.zhengming@h3c.com> wrote:
>
>> From: Zhang Zhengming <zhang.zhengming@h3c.com>
>> 
>> There is a crash in relay\_file\_read, as the var from 
>> point to the end of last subbuf.
>> The oops looks something like:
>> pc : \_\_arch\_copy\_to\_user+0x180/0x310
>> lr : relay\_file\_read+0x20c/0x2c8
>> Call trace:
>>  \_\_arch\_copy\_to\_user+0x180/0x310
>>  full\_proxy\_read+0x68/0x98
>>  vfs\_read+0xb0/0x1d0
>>  ksys\_read+0x6c/0xf0
>>  \_\_arm64\_sys\_read+0x20/0x28
>>  el0\_svc\_common.constprop.3+0x84/0x108
>>  do\_el0\_svc+0x74/0x90
>>  el0\_svc+0x1c/0x28
>>  el0\_sync\_handler+0x88/0xb0
>>  el0\_sync+0x148/0x180
>> 
>> We get the condition by analyzing the vmcore:
>> 1). The last produced byte and last consumed byte
>>     both at the end of the last subbuf
>> 2). A softirq who will call function(e.g \_\_blk\_add\_trace)
>>     to write relay buffer occurs when an program calling
>>     function relay\_file\_read\_avail.
>>         relay\_file\_read
>>                 relay\_file\_read\_avail
>>                         relay\_file\_read\_consume(buf, 0, 0);
>>                         //interrupted by softirq who will write subbuf
>>                         ....
>>                         return 1;
>>                 //read\_start point to the end of the last subbuf
>>                 read\_start = relay\_file\_read\_start\_pos
>>                 //avail is equal to subsize
>>                 avail = relay\_file\_read\_subbuf\_avail
>>                 //from  points to an invalid memory address             
>>                 from = buf->start + read\_start
>>                 //system is crashed
>>                 copy\_to\_user(buffer, from, avail)
>
> Thanks.  Hopefully Pengcheng Yang and Jens Axboe can comment.
This patch looks good to me.

Reviewed-by: Pengcheng Yang <yangpc@wangsu.com>

\>
> I'm thinking we should backport this into earlier kernels and that the
> commit we're fixing is
>
> Fixes: 341a7213e5c1 ("kernel/relay.c: fix read\_pos error when multiple readers")
I suggest starting backport with this tag:

Fixes: 8d62fdebdaf9 ("relay file read: start-pos fix")

^ permalink raw reply	\[**flat**|nested\] 4+ messages in thread

end of thread, other threads:\[~2023-04-23  8:34 UTC | newest\]

**Thread overview:** 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-04-19  4:02 \[PATCH\] relayfs: fix out-of-bounds access in relay\_file\_read zhangzhengming
2023-04-19 21:03 \` Andrew Morton
2023-04-19 21:07   \` Jens Axboe
2023-04-23  8:28   \` Pengcheng Yang

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-2023-3268: fix out-of-bounds access in relay_file_read

There is a permission and access control vulnerability in some ZTE AndroidTV STBs. Due to improper permission settings, non-privileged application can perform functions that are protected with signature/privilege-level permissions. Exploitation of this vulnerability could clear personal data and applications on the user's device, affecting device operation.

CVE-2023-25645: Security Bulletin Details

jfinal CMS 5.1.0 has an arbitrary file read vulnerability.

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

Pick a username

Email Address

Password

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

Already on GitHub? Sign in to your account

CVE-2023-34645: jfinal CMS v5.1.0 has a arbitrary file reading vulnerability exists · Issue #57 · jflyfox/jfinal_cms

jeecg-boot 3.5.0 and 3.5.1 have a SQL injection vulnerability the id parameter of the /jeecg-boot/jmreport/show interface.

**版本号：**

JECG3.5.1 And JECG3.5.0

**前端版本：vue3版？还是 vue2版？**

vue3

**问题描述：**

After testing, it was found that the id parameter of the/jeecg-boot/jmreport/show interface of jeecg-boot has SQL injection and is unauthorized.

**截图&代码：**

Download and use https://github.com/jeecgboot/jeecg-boot After the project source code starts,  
Entry: "Statistical Report" -->"Example of Building Block Report"  
Grab the package and obtain the SQL injection interface. The following figure proves the existence of SQL injection.  
  

Payload (check MySQL version):  
{"id":"961455b47c0b86dc961e90b5893bff05","apiUrl":"","params":"{"id":"1' or '%1%' like (updatexml(0x3a,concat(1,(select database())),1)) or '%%' like '"}"}  

Payload (view current database):  
{"id":"961455b47c0b86dc961e90b5893bff05","apiUrl":"","params":"{"id":"1' or '%1%' like (updatexml(0x3a,concat(1,(select database())),1)) or '%%' like '"}"}  

Source code analysis:  
In the org. jeecg. modules. jmreport. descreport. a package, a.java is a controller; When it comes to post requests/jeecg boot/jmreport/show, it will come to this method.  

Using burp for contracting  

Then, line 315 passes var3 into jmReportDesignService. show; Let's follow in and take a look.  
  
Enter getDataById on line 2122  
  
Then on line 248, reportDbDao. selectList was called  

Entered the JmReportDb class and obtained dbDynSql as: select \* from rep\_ demo\_ gongsi where id='${id}'。 Confirmed as the ID of the splice  

The interface this.reportDbDao. selectListBySql was called at line 468 in the e-class of the org. jeecg. modules. jmreport. descreport. service. a package.  

This interface is a MyBatis method that uses @ ResultType and @ Param annotations. DbDynSql called  

Finally, the database name was obtained through error injection  

**友情提示（为了提高issue处理效率）：**

*   未按格式要求发帖，会被直接删掉;
*   描述过于简单或模糊，导致无法处理的，会被直接删掉；
*   请自己初判问题描述是否清楚，是否方便我们调查处理；
*   针对问题请说明是Online在线功能(需说明用的主题模板)，还是生成的代码功能；

CVE-2023-34659: Unauthorized SQL injection in Jeecg3.5.0 and 3.5.1 · Issue #4976 · jeecgboot/jeecg-boot

jjeecg-boot V3.5.0 has an unauthorized arbitrary file upload in /jeecg-boot/jmreport/upload interface.

**版本号：**

目前确定影响：3.5.0 & 3.5.1（其它版本未验证）

**前端版本：vue3版？还是 vue2版？**

vue3版

**问题描述：**

经测试发现/jeecg-boot/jmreport/upload接口存在未授权任意文件上传，可以上传html文件造成存储型的XSS。

**截图&代码：**

下载使用https://github.com/jeecgboot/jeecg-boot项目源代码启动项目后，  
入口：“报表设计器”-->"新建报表"-->"插入图片"  
抓取包，获得上传接口，下面证明任意文件上传的存在。  
  
  
  
修改后缀为html，添加js代码  
  
访问后，成功执行  
  
尝试上传sh，上传成功  
  
###源码分析  
在org.jeecg.modules.jmreport.desreport.a包里面的a.java是一个controller；当做post请求/jeecg-boot/jmreport/upload的时候就会来到这个方法里面。

进行判断了之后，然后进入LOCAL方法，我们跟进去一直来到了a方法。这里只是做了“../”的过滤。

然后调用getUpload()获取存储的路径，做了一系列的赋值之后，来到var8得到了最终的路径，然后通过new File传进var8的值，创建了新的文件，至此实现了任意文件类型的上传。

**友情提示（为了提高issue处理效率）：**

*   未按格式要求发帖，会被直接删掉;
*   描述过于简单或模糊，导致无法处理的，会被直接删掉；
*   请自己初判问题描述是否清楚，是否方便我们调查处理；
*   针对问题请说明是Online在线功能(需说明用的主题模板)，还是生成的代码功能；