Microsoft Exchange Server Spoofing Vulnerability

CVE-2021-31209

Microsoft SharePoint Remote Code Execution Vulnerability

CVE-2021-31181

Microsoft Exchange Server Remote Code Execution Vulnerability This CVE ID is unique from CVE-2021-31195.

CVE-2021-31198

Dell EMC Integrated System for Microsoft Azure Stack Hub, versions 1906 – 2011, contain an undocumented default iDRAC account. A remote unauthenticated attacker, with the knowledge of the default credentials, could potentially exploit this to log in to the system to gain root privileges.

**Vaikutus**

High

**Tiedot**

 

**Description**

**CVSS Base Score**

**CVSS Vector String**

 

Dell Integrated System for Microsoft Azure Stack Hub, versions 1906 – 2011, contain an undocumented default iDRAC account. A remote unauthenticated attacker, with the knowledge of the default credentials, may potentially exploit this to log in to the system to gain root privileges.

NOTE: For versions prior to 1906, the account is enabled and documented. For versions after 2011, the account is disabled by default.

8.0

 https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

 

**Description**

**CVSS Base Score**

**CVSS Vector String**

 

Dell Integrated System for Microsoft Azure Stack Hub, versions 1906 – 2011, contain an undocumented default iDRAC account. A remote unauthenticated attacker, with the knowledge of the default credentials, may potentially exploit this to log in to the system to gain root privileges.

NOTE: For versions prior to 1906, the account is enabled and documented. For versions after 2011, the account is disabled by default.

8.0

 https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Dell Technologies suosittelee, että kaikki asiakkaat ottavat huomioon sekä CVSS-peruspistemäärän että kaikki asiaankuuluvat väliaikaiset ja ympäristöön liittyvät pisteet, jotka voivat vaikuttaa tietyn tietoturvahaavoittuvuuden mahdolliseen vakavuuteen.

**Tuotteet, joihin asia vaikuttaa ja tilanteen korjaaminen**

**Product**

**Affected Version(s)**

**Updated Version(s)**

**Link to Update**

Dell Integrated System for Microsoft Azure Stack Hub

versions 1906 – 2011

2102

Link to Install Guide

We recommend all users running versions prior to 2102, disable the default account following the best practices as described in Step 1 of page 12 of the Dell Integrated System for Microsoft  
Azure Stack Hub Patch and Update Installation Guide

**Product**

**Affected Version(s)**

**Updated Version(s)**

**Link to Update**

Dell Integrated System for Microsoft Azure Stack Hub

versions 1906 – 2011

2102

Link to Install Guide

We recommend all users running versions prior to 2102, disable the default account following the best practices as described in Step 1 of page 12 of the Dell Integrated System for Microsoft  
Azure Stack Hub Patch and Update Installation Guide

**Kiitokset**

**Revision**

**Date**

**Description**

1.0

2021-05-04

Initial Release

**Asiaan liittyvät tiedot**

Dell Security Advisories and Notices  
Dell Vulnerability Response Policy  
CVSS Scoring Guide

06 toukok. 2021

CVE-2021-21505: DSA-2021-020: Dell Integrated System for Microsoft Azure Stack Hub Security Update for an iDRAC Undocumented Account Vulnerability

Dell dbutil_2_3.sys driver contains an insufficient access control vulnerability which may lead to escalation of privileges, denial of service, or information disclosure. Local authenticated user access is required.

CVE-2021-21551: DSA-2021-088: Dell Client Platform -suojauspäivitys: Dellin dbutil-ohjaimen riittämätön käytön hallinta -haavoittuvuus

Microsoft’s Section 52, the Azure Defender for IoT security research group, recently uncovered a series of critical memory allocation vulnerabilities in IoT and OT devices that adversaries could exploit to bypass security controls in order to execute malicious code or cause a system crash.
These remote code execution (RCE) vulnerabilities cover more than 25 CVEs and potentially affect a wide range of domains, from consumer and medical IoT to Industrial IoT, Operational Technology (OT), and industrial control systems.

Microsoft’s Section 52, the Azure Defender for IoT security research group, recently uncovered a series of critical memory allocation vulnerabilities in IoT and OT devices that adversaries could exploit to bypass security controls in order to execute malicious code or cause a system crash.

These remote code execution (RCE) vulnerabilities cover more than 25 CVEs and potentially affect a wide range of domains, from consumer and medical IoT to Industrial IoT, Operational Technology (OT), and industrial control systems.

The vulnerabilities exist in standard memory allocation functions spanning widely used real-time operating systems (RTOS), embedded software development kits (SDKs), and C standard library (libc) implementations. These findings have been shared with vendors through responsible disclosure led by the Microsoft Security Response Center (MSRC) and the Department of Homeland Security (DHS), enabling these vendors to investigate and patch the vulnerabilities.

For a full list of affected products and CVEs, please visit the DHS website: ICSA-21-119-04 Multiple RTOS .

Given the pervasiveness of IoT and OT devices, these vulnerabilities, if successfully exploited, represent a significant potential risk for organizations of all kinds. To date, Microsoft has not seen any indications of these vulnerabilities being exploited. However, we strongly encourage organizations to patch their systems as soon as possible.

At the same time, we recognize that patching IoT/OT devices can be complex. For devices that cannot be patched immediately, we recommend mitigating controls such as: reducing the attack surface by minimizing or eliminating exposure of vulnerable devices to the internet; implementing network security monitoring to detect behavioral indicators of compromise; and strengthening network segmentation to protect critical assets, as described in the mitigations section at the end of this blog post.

Note that Microsoft Azure RTOS ThreadX is not vulnerable in its default configuration. The Azure RTOS ThreadX documentation has been updated to state that it is “only safe to disable error checking if the application can absolutely guarantee all input parameters are always valid under all circumstances, including input parameters derived from external input.”

****“BadAlloc”: Running malicious code through vulnerable memory functions** **“BadAlloc”: Running malicious code through vulnerable memory functions****

“BadAlloc” is the name assigned by Microsoft’s Section 52 to the family of vulnerabilities discovered in embedded IoT and OT operating systems and software to describe this class of memory overflow vulnerabilities. All of these vulnerabilities stem from the usage of vulnerable memory functions such as malloc, calloc, realloc, memalign, valloc, pvalloc, and more. Our research shows that memory allocation implementations written throughout the years as part of IoT devices and embedded software have not incorporated proper input validations. Without these input validations, an attacker could exploit the memory allocation function to perform a heap overflow, resulting in execution of malicious code on a target device.

The memory allocation vulnerabilities can be invoked by calling the memory allocation function, such as malloc(VALUE), with the VALUE parameter derived dynamically from external input and being large enough to trigger an integer overflow or wraparound. The concept is as follows: When sending this value, the returned outcome is a freshly allocated memory buffer. While the size of the allocated memory remains small due to the wraparound, the payload associated with the memory allocation exceeds the actual allocated buffer, resulting in a heap overflow. This heap overflow enables an attacker to execute malicious code on the target device. The following are “BadAlloc” examples:

****Mitigating “BadAlloc” vulnerabilities** **Mitigating “BadAlloc” vulnerabilities****

We recommend the following mitigations for organizations with IoT and OT devices:  
• **Patch.** Follow vendor instructions for applying patches to the affected products.  
• **If you can’t patch, monitor**. Since most legacy IoT and OT devices don’t support agents, use an IoT/OT-aware network detection and response (NDR) solution like Azure Defender for IoT and SIEM/SOAR solution like Azure Sentinel to auto-discover and continuously monitor devices for anomalous or unauthorized behaviors, such as communication with unfamiliar local or remote hosts. These are essential elements of implementing a Zero Trust strategy for IoT/OT.  
• **Reduce the attack surface** by eliminating unnecessary internet connections to OT control systems and implementing VPN access with multi-factor authentication (MFA) when remote access is required. The DHS warns that VPN devices may also have vulnerabilities and should be updated to the most current version available.  
• **Segment**. Network segmentation is important for Zero Trust because it limits the attacker’s ability to move laterally and compromise your crown jewel assets, after the initial intrusion. In particular, IoT devices and OT networks should be isolated from corporate IT networks using firewalls.

****About Section 52** **About Section 52****

Microsoft’s Section 52 is the security research group for Azure Defender for IoT. The group is comprised of security researchers and data scientists with deep domain expertise in IoT/OT threat hunting, malware reverse engineering, incident response, and data analysis. The group also provides ongoing threat intelligence updates to Azure Defender for IoT, enabling detection and mitigation of the most recent IoT/OT vulnerabilities and threats.

**AZ Defender team**

“BadAlloc” – Memory allocation vulnerabilities could affect wide range of IoT and OT devices in industrial, medical, and enterprise networks

** DISPUTED ** Unbound before 1.9.5 allows an integer overflow in the regional allocator via regional_alloc. NOTE: The vendor disputes that this is a vulnerability. Although the code may be vulnerable, a running Unbound installation cannot be remotely or locally exploited.

**First, we’d like to thank everyone in the community who donated to the cause and made this happen. Our crucial work does not happen without donations from people who care about our cause. If security and privacy on the web matter to you, there’s a huge number of ways to support us. You can add us to Amazon Smile for free and they will donate a small percentage of their profits to us. You can donate directly using a dozen different methods on the site. You can tell your employer about us. You can go to the community and spread the word. You can volunteer and get involved. Even following our work on social media helps us spread the word. On Twitter we are @ostifofficial and on Reddit we are /u/ostifofficial .**

**The project: Unbound DNS**

From the Unbound website: “Unbound is a validating, recursive, caching DNS resolver. It is designed to be fast and lean and incorporates modern features based on open standards.To help increase online privacy, Unbound supports DNS-over-TLS which allows clients to encrypt their communication. In addition, it supports various modern standards that limit the amount of data exchanged with authoritative servers. These standards do not only improve privacy but also help making the DNS more robust. The most important are Query Name Minimization, the Aggressive Use of DNSSEC-Validated Cache and support for authority zones, which can be used to load a copy of the root zone.Unbound runs on FreeBSD, OpenBSD, NetBSD, MacOS, Linux and Microsoft Windows, with packages available for most platforms. It is included in the base-system of FreeBSD and OpenBSD and in the standard repositories of most Linux distributions. Installation and configuration is designed to be easy. Setting up a resolver for your machine or network can be done with only a few lines of configuration.It is free, open source software under the BSD license. The guiding principles for our product development roadmap are first and foremost the security and privacy of the user. In addition, all functionality must be backed by well established open standards. We continually improve the functionality of Unbound for all of our users…”

**The Scope**

The audit was designed to locate bugs and weaknesses in design that impact the security of servers running Unbound DNS. A combination of manual code auditing, dynamic analysis using a custom fuzzing harness, and  
static analysis was used to perform the audit.

**The Broad Strokes**

Both the audit team and the Unbound team are happy with the results as they are shown. This project led to a total of 48 changes in unbound that either improve security or fix minor issues that could lead to future security problems as the application grows and evolves over time. The consensus is that Unbound has greatly benefited from the work and that the users and applications that depend on it are now safer than they were prior to our work. A patch will be released tomorrow, December 12th 2019. A release candidate patch addressing all outstanding issues is here: https://nlnetlabs.nl/pipermail/unbound-users/2019-December/011930.html all other outstanding issues were corrected in versions 1.9.4 and 1.9.5.

**FIXED** = A patch was applied that corrects this issue.  
**SOLVED** = Clarification given by the Unbound team indicates that the issue does not need patching for other reasons.  
**DISPUTED** = The Unbound team disagrees with the assessment.

If an issue does not have a status, it is because the issue is still being discussed between the teams. It does not indicate a dispute, only that OSTIF does not know the current status. The status of the issues will be updated here as we learn more about them.

**The Detailed Audit Results**

One Critical, Five High, and Five Medium severity issues were found, with an additional 39 issues that were rated as low or informational severity.

**CVE-2019-18934 – CRITICAL – Shell Injection in IPSECMOD  
**FIXED in commit 09845779d5f2c96e3064ff398cad65c08357cfbf

When using the IPSECMOD module, a malicious DNS response from a client can inject commands into the host machine.

**CVE-2019-16866 – HIGH – Uninitialized Memory in worker\_handle\_request()  
**FIXED in commit b60c4a472c856f0a98120b7259e991b3a6507eb5

A use-after-free issue in worker\_handle\_request() can lead to remote code execution or denial of service.

**HIGH – Config Injection in create\_unbound\_ad\_servers.sh  
**FIXED in commit f887552763477a606a9608b0f6b498685e0f6587

The bash script in contrib/create\_unbound\_ad\_servers.sh does not properly sanitize the retrieved data before it is outputted into a configuration file. This allows to modify the configuration by having several statements on a single line. Since the input is retrieved via unencrypted, unauthenticated HTTP an attacker on the wire might be able to abuse this issue.

**HIGH – Integer Overflow in Regional Allocator  
**FIXED in commit 226298bbd36f1f0fd9608e98c2ae85988b7bbdb8

When the regional allocator in util/regional.c is used to allocate memory via regional\_alloc() integer overflows can happen. If size is big enough the first call to malloc() will have a parameter that is  
smaller than expected. Furthermore the macro ALIGN\_UP could overflow causing r->_available_ to point at a bad memory location.

**HIGH – Integer Overflow in sldns\_str2wire\_dname\_buf\_origin()  
**FIXED in commit a3545867fcdec50307c776ce0af28d07046a52dd

The function sldns\_str2wire\_dname\_buf\_origin() in sldns/str2wire.c converts a string to dname wireformat, concatenating with origin when the domain name is relative. Several checks are performed to avoid a buffer overflow when writing the result into buf. Nevertheless, when dlen + origin\_len is bigger than sizeof(size\_t), the calculation will wrap around, resulting in the value of the addition being smaller than the operands. When this happens, the checks might be bypassed and could lead to memmove() writing out of bounds. An out of bounds write produces unexpected results and can usually be abused by an attacker to gain remote code execution.

**HIGH – Out of Bounds Write in sldns\_bget\_token\_par()  
**FIXED in commit fa23ee8f31ba9a018c720ea822faaee639dc7a9c

The function sldns\_bget\_token\_par() in sldns/parse.c returns a token from a buffer. While parsing the input buffer, char by char, certain inputs will result in a write and increment to the token buffer without checking boundary limits. A specially crafted input could repeatedly trigger this unbounded write and eventually perform a write outside of token ’s bounds. An out of bounds write produces unexpected results and can usually be abused by an attacker to gain remote code execution.

**MEDIUM – Assert Causing DoS in synth\_cname()  
**FIXED in commit f5e06689d193619c57c33270c83f5e40781a261d

It is possible to trigger an log\_assert() in synth\_cname() by sending invalid packets to the server. This issue should not be fixed by disabling asserts, as this raises an additional possible integer underflow issue. If asserts are disabled during compilation, this might lead to an out of bounds write in dname\_pkt\_copy() since the computation alias+(qnamelen-dname\_rrset->dname\_len) might become negative due to an underflow.

**MEDIUM – Assert Causing DoS in dname\_pkt\_copy()  
**FIXED in commit d2eb78e871153f22332d30c6647f3815148f21e5

It is possible to trigger an assert() in dname\_pkt\_copy() by sending invalid packets to the server.

**MEDIUM – Integer Overflows in Size Calculations  
**FIXED in commit 02080f6b180232f43b77f403d0c038e9360a460f

In different files and functions sizes are calculated that are later passed on to different allocation functions such as malloc(). Several of these cases are not protected against integer overflows.

**MEDIUM – Insufficient Handling of Compressed Names in dname\_pkt\_copy()  
**FIXED in commit 2d444a5037acff6024630b88092d9188f2f5d8fe

In dname\_pkt\_copy() an infinite loop can be caused by the input data \\xC0\\x00. This will cause the LABEL\_IS\_PTR macro to return true and set lablen to 0, causing the checking to start at the beginning of the input again. Additionally, the log\_assert() can be triggered quite easily, leading to another DoS.

**MEDIUM – Out of Bound Write Compressed Names in rdata\_copy()  
**FIXED in commit 6c3a0b54ed8ace93d5b5ca7b8078dc87e75cd640

In rdata\_copy(), if the len parameter becomes bigger than the size of the packet (pkt\_len ), the memmove() is performed before the check in log\_assert(). _It seems that, due to the fact that packets are first parsed by other functions that check for_  
_unbounded pointers, this might not be exploitable._

**This is a short synopsis of the full report below which contains PoC examples, code snippets, and an additional 70 pages of analysis and issues that were identified to improve code quality and harden Unbound further against attack.**

**The Full Audit Report for Unbound DNS by X41 D-Sec**

X41-Unbound-Security-Audit-2019-Final-Report

REMEMBER THAT THIS WORK DOES NOT GET DONE WITHOUT COMMUNITY SUPPORT. DONATE, TALK ABOUT OUR WORK, AND GET INVOLVED!

CVE-2019-25032: Our Audit of Unbound DNS by X41 D-Sec – Full Results – OSTIF

Improper neutralization of user data in the DjVu file format in ExifTool versions 7.44 and up allows arbitrary code execution when parsing the malicious image

@@ -2,20 +2,76 @@ \# File: acdsee.config # \# Description: This config file defines ACDSee XMP region tags for writing. \# The following tags are created in the XMP-acdsee-rs group # \# Usage: exiftool -config acdsee.config -ACDSEETAG=VALUE FILE ... \# RegionInfoACDSee : The structured tag for the ACDSee regions \# (similar to XMP-mwg-rs:RegionInfo) # \# The following tags are the width, height, and unit of the \# image at the time of processing when storing image region \# metadata. They are similar to the AppliedToDimensions tags \# of the MWG regions. \# ACDSeeRegionAppliedToDimensionsH : Height of the image \# ACDSeeRegionAppliedToDimensionsUnit : Unit of the image \# ACDSeeRegionAppliedToDimensionsW : Width of the image # \# Actual region data, stored in an array. These flattened tags \# are treated as List Type tags. There are two region types, \# the ALYArea and the DLYArea. The ALYArea tags tags assigned \# by ACDSee and are usually square in dimensions. The DLYArea \# tags are both the tags assigned by ACDSee (but possibly \# rectangular instead of square) as well as any manual \# assigned tags. They are similar to the area tags of the MWG \# regions. \# ACDSeeRegionDLYAreaH : Height of DLY region \# ACDSeeRegionDLYAreaW : Width of DLY region \# ACDSeeRegionDLYAreaX : X centerpoint of DLY region \# ACDSeeRegionDLYAreaY : Y centerpoint of DLY region \# ACDSeeRegionALYAreaH : Height of ALY region \# ACDSeeRegionALYAreaW : Width of ALY region \# ACDSeeRegionALYAreaX : X centerpoint of ALY region \# ACDSeeRegionALYAreaY : Y centerpoint of ALY region \# ACDSeeRegionName : Name of region \# ACDSeeRegionType : Type of region \# ACDSeeRegionNameAssignType : How the type was assigned. \# "Manual" is the only known \# entry at this time # \# Conversion tags. These tags can be used to convert other region \# type tags to ACDSee regions. \# MPRegion2ACDSeeRegion : Converts a Microsoft RegionInfoMP \# IPTCRegion2ACDSeeRegion : Converts an IPTC ImageRegion \# MWGRegion2ACDSeeRegion : Converts a MWG RegionInfo # \# Usage: To set individual tags \# exiftool -config acdsee.config -ACDSEETAG=VALUE FILE ... # \# To convert Microsoft Regions to ACDSee regions \# exiftool -config acdsee.config "-RegionInfoACDSee<MPRegion2ACDSeeRegion" File ... \# To convert IPTC regions to ACDSee regions \# exiftool -config acdsee.config "-RegionInfoACDSee<IPTCRegion2ACDSeeRegion" File ... \# To convert MWG Regions to ACDSee regions \# exiftool -config acdsee.config "-RegionInfoACDSee<MWGRegion2ACDSeeRegion" File ... # \# Requires: ExifTool version 10.28 or later # \# Revisions: 2020/01/28 - Bryan K. Williams (aka StarGeek) Created \# 2021/04/08 - BKW Added tags to convert from Microsoft, IPTC, \# and MWG regions to ACDSee regions based upon \# convert\_regions.config. Expanded docs. \# Shortened ADCSee tag names and added shortcuts \# from original names to new names, for example \# "RegionInfoACDSeeAppliedToDimensions\*" -> "ACDSeeRegionAppliedToDimensions\*" \# "RegionInfoACDSeeRegionList\* -> "ACDSeeRegion\*" #------------------------------------------------------------------------------ use Data::Dumper;  
my %sACDSeeDimensions = ( STRUCT\_NAME => 'ACDSee Dimensions', NAMESPACE => {'acdsee-stDim' => 'http://ns.acdsee.com/sType/Dimensions#'}, 'w' \=> { Writable => 'real' }, 'h' \=> { Writable => 'real' }, 'unit' \=> { }, 'w' => { Writable => 'real' }, 'h' => { Writable => 'real' }, 'unit' => { }, );  
my %sACDSeeArea = ( @@ -38,14 +94,120 @@ my %sACDSeeRegionStruct = ( );  
%Image::ExifTool::UserDefined = ( \# new XMP namespaces (eg. xxx) must be added to the Main XMP table: \# new XMP namespaces for ACDSee regions 'Image::ExifTool::XMP::Main' => { 'acdsee-rs' => { # <-- must be the same as the NAMESPACE prefix SubDirectory => { TagTable => 'Image::ExifTool::UserDefined::ACDSeeRegions' }, }, }, 'Image::ExifTool::Composite' => { \# create an ACDSee RegionInfo structure from a Microsoft RegionInfoMP structure MPRegion2ACDSeeRegion => { Require => { 0 => 'RegionInfoMP', 1 => 'ImageWidth', 2 => 'ImageHeight', }, ValueConv => q{ my ($rgn, @newRgns); foreach $rgn (@{$val\[0\]{Regions}}) { my $name = $$rgn{PersonDisplayName}; next unless $$rgn{Rectangle} or defined $name; my %newRgn = ( Type => 'Face' ); if (defined $name) { \# don't add ignored faces next if $name eq 'ffffffffffffffff'; $newRgn{Name} = $name; } if ($$rgn{Rectangle}) { my @rect = split /\\s\*,\\s\*/, $$rgn{Rectangle}; $newRgn{DLYArea} = { X => $rect\[0\] + $rect\[2\]/2, Y => $rect\[1\] + $rect\[3\]/2, W => $rect\[2\], H => $rect\[3\], } if @rect == 4; } push @newRgns, \\%newRgn; } return { AppliedToDimensions => { W => $val\[1\], H => $val\[2\], Unit => 'pixel' }, RegionList => \\@newRgns, }; }, }, \# create an ACDSee RegionInfo structure from an IPTC ImageRegion list IPTCRegion2ACDSeeRegion => { Require => { 0 => 'ImageRegion', 1 => 'ImageWidth', 2 => 'ImageHeight', }, ValueConv => q{ my ($rgn, @newRgns); my $rgns = ref $val\[0\] eq 'ARRAY' ? $val\[0\] : \[ $val\[0\] \]; foreach $rgn (@$rgns) { my %newRgn = ( Type => 'Face' ); if ($$rgn{RegionBoundary} and $$rgn{RegionBoundary}{RbShape} eq 'rectangle') { my @rect = @{$$rgn{RegionBoundary}}{'RbX','RbY','RbW','RbH'}; if ($$rgn{RegionBoundary}{RbUnit} eq 'pixel') { $rect\[0\] /= $val\[1\], $rect\[2\] /= $val\[1\]; $rect\[1\] /= $val\[2\]; $rect\[3\] /= $val\[2\]; } $newRgn{'DLYArea'} = { X => $rect\[0\] + $rect\[2\]/2, Y => $rect\[1\] + $rect\[3\]/2, W => $rect\[2\], H => $rect\[3\], }; } else { next unless defined $$rgn{Name}; } $newRgn{Name} = $$rgn{Name} if defined $$rgn{Name}; push @newRgns, \\%newRgn; } return { AppliedToDimensions => { 'W' => $val\[1\], 'H' => $val\[2\], 'Unit' => 'pixel' }, RegionList => \\@newRgns, }; }, },  
\# create an MWG RegionInfo structure from an IPTC ImageRegion list MWGRegion2ACDSeeRegion => { Require => { 0 => 'RegionInfo', 1 => 'ImageWidth', 2 => 'ImageHeight', }, ValueConv => q{ my ($rgn, @newRgns); my %newRgn; foreach $rgn (@{$val\[0\]{RegionList}}) { next unless $$rgn{Area} or defined $$rgn{Name}; my %newRgn; if ($$rgn{Area}) { $newRgn{'DLYArea'} = { 'X' => $$rgn{Area}{'X'}, 'Y' => $$rgn{Area}{'Y'}, 'W' => $$rgn{Area}{'W'}, 'H' => $$rgn{Area}{'H'}, }; }; $newRgn{Name} = $$rgn{Name} if defined $$rgn{Name}; $newRgn{'Type'} = $$rgn{'Type'} if defined $$rgn{'Type'}; push @newRgns, \\%newRgn; } return { 'AppliedToDimensions' => $val\[0\]{'AppliedToDimensions'}, RegionList => \\@newRgns, } }, }, #### }, );  
%Image::ExifTool::UserDefined::ACDSeeRegions = ( @@ -54,18 +216,43 @@ my %sACDSeeRegionStruct = ( WRITABLE => 'string', # (default to string-type tags) Regions => { Name => 'RegionInfoACDSee', FlatName => 'ACDSee', \# the "Struct" entry defines the structure fields Struct => { \# optional structure name (used for warning messages only) STRUCT\_NAME => 'ACDSee RegionInfo', RegionList => { FlatName => 'Region', Struct => \\%sACDSeeRegionStruct, List => 'Bag', }, AppliedToDimensions => { Struct => \\%sACDSeeDimensions }, AppliedToDimensions => { FlatName => 'RegionAppliedToDimensions',Struct => \\%sACDSeeDimensions }, }, }, );  
\# Shortcuts to old names added so as not to break previously used commands %Image::ExifTool::UserDefined::Shortcuts = ( RegionInfoACDSeeAppliedToDimensionsH => 'ACDSeeRegionAppliedToDimensionsH', RegionInfoACDSeeAppliedToDimensionsUnit => 'ACDSeeRegionAppliedToDimensionsUnit', RegionInfoACDSeeAppliedToDimensionsW => 'ACDSeeRegionAppliedToDimensionsW', RegionInfoACDSeeRegionListDLYAreaH => 'ACDSeeRegionDLYAreaH', RegionInfoACDSeeRegionListDLYAreaW => 'ACDSeeRegionDLYAreaW', RegionInfoACDSeeRegionListDLYAreaX => 'ACDSeeRegionDLYAreaX', RegionInfoACDSeeRegionListDLYAreaY => 'ACDSeeRegionDLYAreaY', RegionInfoACDSeeRegionListALGAreaH => 'ACDSeeRegionALGAreaH', RegionInfoACDSeeRegionListALGAreaW => 'ACDSeeRegionALGAreaW', RegionInfoACDSeeRegionListALGAreaX => 'ACDSeeRegionALGAreaX', RegionInfoACDSeeRegionListALGAreaY => 'ACDSeeRegionALGAreaY', RegionInfoACDSeeRegionListName => 'ACDSeeRegionName', RegionInfoACDSeeRegionListType => 'ACDSeeRegionType', RegionInfoACDSeeRegionListNameAssignType => 'ACDSeeRegionNameAssignType', );  
\# Forced -struct option during debugging #%Image::ExifTool::UserDefined::Options = ( \# Struct => 1, #); #------------------------------------------------------------------------------ 1; #end

Tag

#microsoft