Google and other firms are adding security configuration to software so cloud applications and services have well-defined security settings — a key component of DevSecOps.

The increased adoption of cloud infrastructure by companies looking to improve agility and support a hybrid workforce has led to more development teams adopting security-as-code as a way to build security into software and products.

Over the past year, for example, Google has pushed security-as-code as a fundamental component of its cloud offerings, identifying in January "software-defined infrastructure" as one of the eight megatrends driving the security of the cloud. Encoding security configuration as code that can be an input into development and deployment processes lets organizations analyze their security configuration, change and redeploy easily, and continuously monitor the state of their security configuration to evaluate whether it matches policies.

The result is analyzable security configuration and continuously verifiable controls, says Phil Venables, vice president at Google and CISO for Google Cloud.

"The great thing about security-as-code is that you know the configuration that you have deployed exactly corresponds to what you had specified and analyzed as meeting your security requirements," he says. "Many breaches out there are not necessarily the result of an unknown risk, but are usually the result of some control that the organization thought they had not being deployed and operating when they needed it the most."

Security-as-code is an extension of the infrastructure-as-code movement that has come about as software-defined networks and systems have become more popular. DevOps teams have adopted infrastructure-as-code as the de facto standard for building and deploying software, containers, and virtual machines, but now companies are betting that the shift to cloud-native infrastructure will make security-as-code a key part of a sustainable approach to security.

**How Security-as-Code Works**  
In 2021, consulting firm McKinsey and Company identified security-as-code as perhaps the only way to secure cloud application and infrastructure at the speed at which modern businesses move.

"Capturing value in the cloud requires most companies to build a transformation engine ... to integrate cloud into business and technologies, drive adoption in priority business domains, and establish the foundational capabilities required to scale cloud usage safely and economically," the consulting firm wrote in a position paper. "SaC is the mechanism for developing foundational capabilities in cloud security and risk management."

Google intends to make the concept much more functional and part of any cloud infrastructure. In November, the company's Cybersecurity Action Team announced a Risk and Compliance as Code (RCaC) solution.

Companies that have embraced DevOps know that repeatable software builds rely on being able to specify the configuration of infrastructure elements — whether software applications, pipeline builds, or containers — as code in a file. This infrastructure-as-code approach allows developers and operations specialists to express and analyze the configuration before it is deployed.

Security-as-code aims to do the same thing for security, in an approach that many have called DevSecOps. Security-as-code expresses the security configuration of a variety of elements, including what security testing should be performed, the criteria for vulnerability scanning, encryption requirements, and access controls.

**How Does it Affect SBOMs?**  
Google sees the current efforts to make software bills of materials (SBOMs) more explicit and functional as a key component of the future of software-as-code. The components of a software program could be analyzed during any build and the policies described in the security-as-code file would be applied. Using a component that is vulnerable to a specific threat, such as Log4j, could stop the build. Other requirements, such as a high level in the Supply Chain Levels for Software Artifacts (SLSA), could also be specified, Google's Venable says.

"This mechanism allows you to start making richer decisions," he says. "This programmability of the environment to enforce security policy is pretty transformational compared to what any of us used to be able to do in traditional on-premise environments."

Google is joined by others blazing a trail into the security-as-code arena. The growing movement to encode security as a configuration file that can be incrementally improved led security firm Tenable Network Security to acquire Accurics, a maker of security-as-code technology.

"It's far more effective to find and fix the issues at the point of creation in code, rather than where they manifest in the cloud," Renaud Deraison, chief technology officer for Tenable Network Security, said in a blog announcing the acquisition. "In this way, we can ensure that what is deployed is secure by default and that any fixes are a simple merge request rather than a patch or operational afterthought."

Not everyone is convinced that security configurations will be ensconced in code anytime soon. While configuration files traveling along with software-defined infrastructure components could bring significant benefits — such as the audit ability and improved change management — companies are still too reactionary to adopt the technology, says Brian Fox, chief technology officer and co-founder of Sonatype, a software-management and security firm.

Software composition analysis (SCA) services that can automate the identification of risky software components — a service that Sonatype provides — provides some of the automated benefits of security-as-code. Most businesses have no idea of even what components make up their software, Fox says.

"We are super early in the adoption cycle with this," he says. "All the reasons that infrastructure-as-code made sense will make sense with security-as-code, but the industry is not quite there yet, because so many people do not have the mechanisms to even do this, never mind doing it as code."

Security-as-Code Gains More Support, but Still Nascent

Zoho ManageEngine ADSelfService Plus before 6121, ADAuditPlus 7060, Exchange Reporter Plus 5701, and ADManagerPlus 7131 allow NTLM Hash disclosure during certain storage-path configuration steps.

CVE-2022-29457: ADSelfService Plus Release Notes

IT departments must account for the business impact and security risks such applications introduce.

Last month, Dark Reading released an enterprise application security survey that raised serious concerns by IT and security teams about the state of low-code/no-code applications. The survey exposed a deep lack of visibility, control, and knowledge necessary to maintain the level of security maturity expected in the enterprise. Here we will look at concrete concerns raised by the survey, examine their root causes, and offer recommendations on ways to address them today.

The following concerns were raised under the question, "What security concerns do you have regarding low-code/no-code applications?"

**Concern No. 1: Governance**  
According to 32% of respondents, "There is no governance over how these applications are accessing and using our data."

Indeed, many useful low-code/no-code applications rely on storing data either in managed storage provided by the platform or in another platform via a connector. The tricky part is that low-code/no-code platforms make it extremely easy for makers to essentially bake their identity into the applications, so that every application user ends up triggering operations on behalf of the maker. Within enterprise environments, it is not uncommon for useful business applications to store their data in the maker's Dropbox or OneDrive account. Baked-in accounts can become an even bigger issue when an honest mistake causes data to be stored in a personal rather than business account.

Another popular use of low-code/no-code are data-movers or operation-stitchers. They connect source and destination, either by moving data between multiple points or by linking together an operation in one system to another in a different system.

As an example, a popular automation flow in enterprise scenarios is email forwarding. Users build an application that monitors their professional inbox for new emails, copies their content, and pastes it in their personal email for various reasons. Note that by copying the data, users are easily able to bypass DLP controls that would have prevented email forwarding.

**Concern No. 2: Trust**  
According to 26% of respondents, "I don't trust the platforms used to create the applications."

Low-code/no-code platform vendors are increasingly directing their attention to provide strong security assurance for their platforms, but there is a long way to go. While enterprise customers have become used to the security benefits provided by public cloud vendors, with their mature security teams, vulnerability disclosure programs, and state-of-the-art SOCs, low-code/no-code platforms are just getting used to the fact that they are now business-critical systems.

Of course, vendors investing in the security of their platform is not enough. Customers have to hold their part of the shared responsibility model, too. While platform vendors are improving their security posture, enterprises using low-code/no-code platforms must figure out how to approach these applications with the same level of security vigor as they would their pro-code applications. After all, the impact of both types of applications on data, identity, and the enterprise as a whole is the same.

Take security testing, for example. To catch security issues early, pro-code applications are typically built with code and configuration scanning tools in place, as part of the CI/CD. There are a host of tools to help detect issues throughout the SDLC, including SAST, DAST, and SCA, which has become very popular in recent years with the rise in open source security issues. Low-code/no-code applications are prone to the same problems that these tools detect, such as injection-based attacks, security misconfiguration, and untrusted dependencies. However, these applications typically rely on manual processes for security assurance or try to use pro-code tools to scan artifacts generated with low-code; unfortunately, pro-code tools fail to understand the business logic of low-code/no-code applications and therefore provide little value.

**Concern No. 3: AppSec**  
According to 26% of respondents, "I don't know how to check for security vulnerabilities in these applications."

How do I make sure my code makes sense, and that it is secure and robust, without access to that code? This point is tricky, and new solutions are required to tackle it.

When public cloud providers started introducing the concept of platform-as-a-service for compute services such as managed virtual machines (VMs), managed Kubernetes clusters, or serverless functions, the same kind of concerns were raised. Our entire strategy, as a security community, to secure compute instances was based on our ability to observe and leverage the host machine running our applications. While stripping away the complexities of managing VMs, cloud providers also stripped away the ability of security teams to observe and protect them. As a result, novel solutions had to be introduced to provide the same level of security assurance with cloud-native building blocks.

The same approach is desperately needed in low-code/no-code applications. Instead of trying to apply existing tools like code scanning or web security monitoring to artifacts generated by low-code/no-code, security teams should adopt solutions that understand the language of low-code/no-code in order to identify logical vulnerabilities in those applications.

**Concern No. 4: Visibility**  
According to 25% of respondents, "The security team doesn't know what applications are being created."

This point is particularly important because you can't protect what you can't see. Most low-code/no-code platforms have little to no capabilities for allowing admins to view applications built on these platforms. Basic questions like, "How many applications do we have?" are simply unanswerable without pervasive measures. For example, some platforms allow admins to make themselves the owners of every application separately but do not allow them to see the application otherwise. So admins must resort to an active change on the platform to take a look at the application. 

Other platforms go even further, allowing business users to create applications in a private folder that administrators cannot review, other than knowing the number of applications that exist in them. A maker could be exfiltrating data through a private application, and the admin is left with no way to even know anything besides the fact that the application exists.

Visibility becomes even trickier once companies realize that they are using more than one low-code/no-code platform. In fact, most large enterprises are already using multiple platforms. With low-code/no-code platforms becoming more popular, citizen development tools being introduced bottom-up, and software-as-a-service (SaaS) vendors becoming platforms themselves, it's clear why enterprises are suddenly finding themselves using several different platforms.

**Concern No. 5: Knowledge and Awareness**  
According to 33% of respondents, "I don't have any security concerns," "Other," or "Don't know."

Since low-code/no-code platforms often find their way into the enterprise through business units rather than top-down through IT, they can easily slip through the cracks and be missed by security and IT teams. While security teams are in most cases part of the procurement process, it's easy to treat a low-code/no-code platform as just another SaaS application used by the business, not realizing that the result of adopting this platform would be empowering a whole array of new citizen-developers in the business.

In one large organization, citizen-developers in the finance team built an expense management application to replace a manual process filled with back-and-forth emails. Employees quickly adopted the application since it made it easier for them to get reimbursed. The finance team was happy because it automated part of its repetitive work. But IT and security were not in the loop. It took some time for them to notice the application, understand that it was built outside of IT, and reach out to the finance team to bring the app under the IT umbrella.

Security and IT teams are always in a state where the backlog of concerns is much larger than their ability to invest. To make sure resources are allocated to the most critical security risks, teams must first be aware of the criticality of low-code/no-code applications to the business and the security risks that they introduce. For the former, this means that low-code/no-code applications' impact on the enterprise must be demonstrated and clear. Security teams must be part of the discussion when thinking about adopting citizen development. 

For the latter, we as a community have to research, categorize, and share concrete security risks we identify to help others to build more secure applications. Bringing IT and security into the low-code/no-code conversation would allow the adoption of these technologies to accelerate, unleashing their full potential to increase business velocity and productivity.

Why So Many Security Experts Are Concerned About Low-Code/No-Code Apps

There is an integer overflow vulnerability in dcraw. When the victim runs dcraw with a maliciously crafted X3F input image, arbitrary code may be executed in the victim's system.

![version graph](https://bugs.debian.org/cgi-bin/version.cgi?width=2;package=dcraw;found=dcraw%2F9.28-2;collapse=1;fixed=dcraw%2F9.28-3;absolute=0;height=2)

Reported by: Wooseok Kang <kangwoosuk1@gmail.com>

Date: Mon, 8 Mar 2021 04:42:02 UTC

Severity: normal

Tags: security, upstream

Found in version dcraw/9.28-2

Fixed in version dcraw/9.28-3

**Done:** Filip Hroch <hroch@physics.muni.cz>

Reply or subscribe to this bug.

Toggle useless messages

**Report forwarded** to `debian-bugs-dist@lists.debian.org, kangwoosuk1@gmail.com, Debian Astronomy Team <debian-astro-maintainers@lists.alioth.debian.org>`:  
`Bug#984761`; Package `dcraw`. (Mon, 08 Mar 2021 04:42:04 GMT) (full text, mbox, link).

**Acknowledgement sent** to `Wooseok Kang <kangwoosuk1@gmail.com>`:  
New Bug report received and forwarded. Copy sent to `kangwoosuk1@gmail.com, Debian Astronomy Team <debian-astro-maintainers@lists.alioth.debian.org>`. (Mon, 08 Mar 2021 04:42:05 GMT) (full text, mbox, link).

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

\[Message part 1 (text/plain, inline)\]

Package: dcraw
Version: 9.28-2
Severity: normal
X-Debbugs-Cc: kangwoosuk1@gmail.com

Dear Maintainer,

There is an integer overflow vulnerability in dcraw.
When the victim runs dcraw with a maliciously crafted X3F input image,
arbitrary code may be executed in the victim's system.

The vulnerability resides in foveon\_load\_camf() function in dcraw.c file.
The program reads data from the input image using get4().

type = get4();  get4();  get4();
wide = get4();
high = get4();

Since there is no sanitization for these variables, we can set their values freely.
Let type=4, and wide and high are enough large values which can make overflow.
Then, it will lead to small memory allocation at the below code.

} else if (type == 4) {
    free (meta\_data);
    meta\_length = wide\*high\*3/2;
    meta\_data = (char \*) malloc (meta\_length);

Therefore, when we read data to this allocated buffer,
it causes the buffer overrun which may lead to arbitrary code execution or program crash.

I attach the maliciously crafted X3F file which crashes dcraw like below.
> dcraw dcraw-poc.X3F
dcraw-poc.X3F: Corrupt data near 0x651
\[1\]    1251 segmentation fault  dcraw dcraw-poc.X3F

Thank you.

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86\_64)

Kernel: Linux 5.4.72-microsoft-standard-WSL2 (SMP w/16 CPU threads)
Locale: LANG=en\_US.UTF-8, LC\_CTYPE=en\_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages dcraw depends on:
ii  libc6            2.31-9
ii  libjpeg62-turbo  1:2.0.6-2
ii  liblcms2-2       2.12~rc1-2

dcraw recommends no packages.

Versions of packages dcraw suggests:
pn  gphoto2  <none>
pn  netpbm   <none>

-- no debconf information

\[dcraw-poc.X3F (image/x-x3f, attachment)\]

**Information forwarded** to `debian-bugs-dist@lists.debian.org, Debian Astronomy Team <debian-astro-maintainers@lists.alioth.debian.org>`:  
`Bug#984761`; Package `dcraw`. (Tue, 09 Mar 2021 16:54:02 GMT) (full text, mbox, link).

**Acknowledgement sent** to `Filip Hroch <hroch@physics.muni.cz>`:  
Extra info received and forwarded to list. Copy sent to `Debian Astronomy Team <debian-astro-maintainers@lists.alioth.debian.org>`. (Tue, 09 Mar 2021 16:54:02 GMT) (full text, mbox, link).

Message #10 received at 984761@bugs.debian.org (full text, mbox, reply):

Dear Wooseok,

I'll look on this.

Note, that I'm maintaining only Debian packaging.
I am not upstream autor; I can fix only the bugs
which does not induce extensive changes in whole
structure of the source code.

FH
--
F. Hroch <hroch@physics.muni.cz>, Masaryk University, Brno, 
Czechia.
Dept. of theor. physics and astrophysics, Kotlarska 2, CZ-611 37.

**Added tag(s) security.** Request was from `Adrian Bunk <bunk@debian.org>` to `control@bugs.debian.org`. (Mon, 31 May 2021 20:51:02 GMT) (full text, mbox, link).

**Information forwarded** to `debian-bugs-dist@lists.debian.org, Debian Astronomy Team <debian-astro-maintainers@lists.alioth.debian.org>`:  
`Bug#984761`; Package `dcraw`. (Wed, 02 Jun 2021 20:42:02 GMT) (full text, mbox, link).

**Acknowledgement sent** to `Salvatore Bonaccorso <carnil@debian.org>`:  
Extra info received and forwarded to list. Copy sent to `Debian Astronomy Team <debian-astro-maintainers@lists.alioth.debian.org>`. (Wed, 02 Jun 2021 20:42:02 GMT) (full text, mbox, link).

Message #17 received at 984761@bugs.debian.org (full text, mbox, reply):

Hi Filip, Wooseok

On Tue, Mar 09, 2021 at 05:41:51PM +0100, Filip Hroch wrote:
> Dear Wooseok,
> 
> I'll look on this.
> 
> Note, that I'm maintaining only Debian packaging.
> I am not upstream autor; I can fix only the bugs
> which does not induce extensive changes in whole
> structure of the source code.

Can you please report the issue upstream? Or was this reported
upstream?

Regards,
Salvatore

**Message sent on** to `Wooseok Kang <kangwoosuk1@gmail.com>`:  
Bug#984761. (Wed, 02 Jun 2021 20:42:07 GMT) (full text, mbox, link).

**Information forwarded** to `debian-bugs-dist@lists.debian.org, Debian Astronomy Team <debian-astro-maintainers@lists.alioth.debian.org>`:  
`Bug#984761`; Package `dcraw`. (Thu, 03 Jun 2021 10:45:03 GMT) (full text, mbox, link).

**Acknowledgement sent** to `Filip Hroch <hroch@physics.muni.cz>`:  
Extra info received and forwarded to list. Copy sent to `Debian Astronomy Team <debian-astro-maintainers@lists.alioth.debian.org>`. (Thu, 03 Jun 2021 10:45:03 GMT) (full text, mbox, link).

Message #25 received at 984761@bugs.debian.org (full text, mbox, reply):

Dear Salvatore,

unfortunatelly, I have not fixed it yet.

I suppose to report it to upstream author -- Mr. Coffin.
In past, I send patches without any response.

The last upstream version of dcraw has been issued
tree years ago, so I've some worry about him.

Regards,
FH


Salvatore Bonaccorso <carnil@debian.org> writes:

> Hi Filip, Wooseok
>
> On Tue, Mar 09, 2021 at 05:41:51PM +0100, Filip Hroch wrote:
>> Dear Wooseok,
>>
>> I'll look on this.
>>
>> Note, that I'm maintaining only Debian packaging.
>> I am not upstream autor; I can fix only the bugs
>> which does not induce extensive changes in whole
>> structure of the source code.
>
> Can you please report the issue upstream? Or was this reported
> upstream?
>
> Regards,
> Salvatore


--
F. Hroch <hroch@physics.muni.cz>, Masaryk University,
Dept. of theor. physics and astrophysics, Brno, Moravia, CZ

**Message sent on** to `Wooseok Kang <kangwoosuk1@gmail.com>`:  
Bug#984761. (Thu, 03 Jun 2021 10:45:06 GMT) (full text, mbox, link).

**Changed Bug title to 'dcraw: CVE-2021-3624: buffer-overflow caused by integer-overflow in foveon\_load\_camf()' from 'dcraw: buffer-overflow caused by integer-overflow in foveon\_load\_camf()'.** Request was from `Salvatore Bonaccorso <carnil@debian.org>` to `control@bugs.debian.org`. (Tue, 29 Jun 2021 05:45:05 GMT) (full text, mbox, link).

**Reply sent** to `Filip Hroch <hroch@physics.muni.cz>`:  
You have taken responsibility. (Thu, 25 Nov 2021 13:06:14 GMT) (full text, mbox, link).

**Notification sent** to `Wooseok Kang <kangwoosuk1@gmail.com>`:  
Bug acknowledged by developer. (Thu, 25 Nov 2021 13:06:15 GMT) (full text, mbox, link).

Message #35 received at 984761-close@bugs.debian.org (full text, mbox, reply):

Source: dcraw
Source-Version: 9.28-3
Done: Filip Hroch <hroch@physics.muni.cz>

We believe that the bug you reported is fixed in the latest version of
dcraw, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 984761@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Filip Hroch <hroch@physics.muni.cz> (supplier of updated dcraw package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Format: 1.8
Date: Sun, 21 Nov 2021 23:15:39 +0100
Source: dcraw
Architecture: source
Version: 9.28-3
Distribution: unstable
Urgency: medium
Maintainer: Debian Astronomy Team <debian-astro-maintainers@lists.alioth.debian.org>
Changed-By: Filip Hroch <hroch@physics.muni.cz>
Closes: 478701 914447 914453 914454 914459 984761
Changes:
 dcraw (9.28-3) unstable; urgency=medium
 .
   \* Written wrappers of fread(),fwrite(),fseek() library functions which
     checks their return values. If an input/output failure is detected,
     dcraw immediately exits with non-zero status and prints a descriptive
     message. Closes: #478701, #914447, #914453, #914454, #914459, #984761
   \* Updated links; upstream has been moved to a new site.
   \* Updated packaging: evolving standards, added metadata, lintian.
Checksums-Sha1:
 25dc6466c9400cbb583545d7ee4311352286ad05 1978 dcraw\_9.28-3.dsc
 cb2b167a49544b5bf879d4a2ef8970b9390b0631 6865640 dcraw\_9.28-3.debian.tar.xz
Checksums-Sha256:
 9927b846c8f93188ae84bcd7831d6d61bc83561dba7ba2440b6dafd18ca4b74d 1978 dcraw\_9.28-3.dsc
 357ef76c9ad7c0f16f12a29d81a1dc3ee8dff1099c30636fc38fb4109f6a3db6 6865640 dcraw\_9.28-3.debian.tar.xz
Files:
 da4d8776a65a9ac1e37c5ee6a272fd5b 1978 graphics optional dcraw\_9.28-3.dsc
 d05b8ef6e95acc707c5d43b82bb9ee02 6865640 graphics optional dcraw\_9.28-3.debian.tar.xz

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEuvxshffLFD/utvsVcRWv0HcQ3PcFAmGfguIACgkQcRWv0HcQ
3PfJLg/+McreFSi3qAg/tpwPYNMXhrQIrhK3KaCdQaJFxkTajhI2j9MeESE4UZYk
V1uDMqtcvbUJP9vSCQDr9z2q66h4u877ckI3nys/ueNKSQM5NRyTcWjzuqCMZdSz
0LZ6qO/UftRIn3HxYWWYZDgO+36I7u5Ua4wPNm+dYCqNED2sALK3sZKBd2WiVfhE
HMbHnpiMLwPVCO4RUVG1uDht0fsHPaV4rPEo0JPvipwHnpgrAKcGP55r+5EGbPdL
HuTahEDiZKhl4MBIEVHAuC2wN8HPhTpONhxIvDbrQm/HLIwm/XPt/N9QTXbv0miW
b204OoXkT33LP8eRz+U3tDpGxQU/dnEZ05sClfV+85n1Tw9Atzle/tqyeg8dVscv
jUmCu10q3ESubpnU4Opdxcm5qt5QB59z6gFnd5wzyaVQehRcGg/luUaeneqguWxz
U82aiwosXEmioXPYeDAzmkjULD1iguwAnSx6BNVGzf/t3XReVW07bFXsnpT8XASc
0LzzKA3Mzjt0y8UM9YvV9vs0SIXuxWLQa5WUfK41TG1wza8wBMewuUQJ2+r16lmG
mYrXb2vz8/8nU2jz+RdUQvhYXSWrRaiQ3Vj+Qcx8eSrveaCLM8RZqgKf6m6STev5
zIz4iwhJZVz78n+M2aci/tjZ+Fhr9RLCuZRDakQFOv5Cq5XzJJk=
=3QxF
-----END PGP SIGNATURE-----

**Bug archived.** Request was from `Debbugs Internal Request <owner@bugs.debian.org>` to `internal_control@bugs.debian.org`. (Sat, 25 Dec 2021 07:29:15 GMT) (full text, mbox, link).

**Bug unarchived.** Request was from `Salvatore Bonaccorso <carnil@debian.org>` to `control@bugs.debian.org`. (Wed, 13 Apr 2022 05:00:02 GMT) (full text, mbox, link).

**Added tag(s) upstream.** Request was from `Salvatore Bonaccorso <carnil@debian.org>` to `control@bugs.debian.org`. (Wed, 13 Apr 2022 05:00:03 GMT) (full text, mbox, link).

Send a report that this bug log contains spam.

Debian bug tracking system administrator <owner@bugs.debian.org\>. Last modified: Mon Apr 25 16:12:34 2022; Machine Name: bembo

Debian Bug tracking system

Debbugs is free software and licensed under the terms of the GNU Public License version 2. The current version can be obtained from https://bugs.debian.org/debbugs-source/.

Copyright © 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson, 2005-2017 Don Armstrong, and many other contributors.

CVE-2021-3624: #984761 - dcraw: CVE-2021-3624: buffer-overflow caused by integer-overflow in foveon_load_camf()

An exploitable vulnerability exists in the way Pixar OpenUSD 20.05 handles file offsets in binary USD files. A specially crafted malformed file can trigger an arbitrary out-of-bounds memory access that could lead to the disclosure of sensitive information. This vulnerability could be used to bypass mitigations and aid additional exploitation. To trigger this vulnerability, the victim needs to access an attacker-provided file.

**Summary**

An exploitable vulnerability exists in the way Pixar OpenUSD 20.05 handles file offsets in binary USD files. A specially crafted malformed file can trigger an arbitrary out-of-bounds memory access that could lead to the disclosure of sensitive information. This vulnerability could be used to bypass mitigations and aid additional exploitation. To trigger this vulnerability, the victim needs to access an attacker-provided file.

**Tested Versions**

Pixar OpenUSD 20.05  
Apple macOS Catalina 10.15.3

**Product URLs**

https://openusd.org

**CVSSv3 Score**

4.3 - CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N

**CWE**

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

**Details**

OpenUSD stands for “Open Universal Scene Descriptor” and is a software suite by Pixar that facilitates, among other things, interchange of arbitrary 3-D scenes that may be composed of many elemental assets.

Most notably, USD and its backing file format `usd` are used on Apple iOS and macOS as part of ModelIO framework in support of SceneKit and ARKit for sharing and displaying 3D scenes in, for example, augmented reality applications. On macOS, these files are automatically rendered to generate thumbnails, while on iOS they can be shared via iMessage and opened with user interaction.

USD binary file format consists of a header pointing to a table of contents that in turn points to individual sections that comprise the whole file. Pointer to a table of contents, as well as back to individual sections from the table of contents, is represented as a 64 bit integer specifying a file offset where the table of contents, or specific section, can be found.

For example, table of contents is read using the following code:

    template <class Reader>
    CrateFile::_TableOfContents
    CrateFile::_ReadTOC(Reader reader, _BootStrap const &b) const
    {
        reader.Seek(b.tocOffset);                                        [1]
        return reader.template Read<_TableOfContents>();                 [2]
    }
    

At \[1\] , table of contents offset read from the file header is used to seek into the file and then the parser proceeds to parse the table of contents at \[2\]. When dealing with regular files, `seek` operations usually just shift the current file pointer to the specified offset, however in most practical uses of OpenUSD (including macOS and iOS utilities and applications) USD file will first be memory mapped. When seek is executed, no check is performed to ensure the offset still falls inside the currently memory mapped file. Since the `b.tocOffset` is a 64 bit integer that is read directly from the mapped file, this can be used to access and read any address in process’ address space.

Similarly to above example, same issue can be triggered when trying to parse individual sections of the file. Following code that parses `FIELDS` section illustrates this:

    template <class Reader>
    void
    CrateFile::_ReadFieldSets(Reader reader)
    {
        TfAutoMallocTag tag("_ReadFieldSets");
        if (auto fieldSetsSection = _toc.GetSection(_FieldSetsSectionName)) {               [3]
            reader.Seek(fieldSetsSection->start);                                           [4]
    
            if (Version(_boot) < Version(0,4,0)) {                                          [5]
                _fieldSets = reader.template Read<decltype(_fieldSets)>();
            } else {
                // Compressed fieldSets in 0.4.0.
                auto numFieldSets = reader.template Read<uint64_t>();
                _fieldSets.resize(numFieldSets);
    

When parsing the `FIELDS` section, an offset from table of contents is retrieved at \[3\] and used in a call to `Seek` at 4. Then at \[5\] the parsing continues. Again, no check is performed to ensure that the offset falls inside the file, enabling arbitrary memory read. While only `FIELDS` section example is given here, other section offsets are vulnerable, too.

USD files are usually distributed as `usdz` archives which can contains multiple distinct `usd` files each referencing each other, with careful file layout , this sort of vulnerability could be abused to probe the memory layout and influence which files are successfully loaded. This could be abused to achieve information leak and defeat exploitation mitigations such as ASLR.

**Crash Information**

This vulnerability has been tested on latest version of macOS Catalina 10.15.3.

    Current executable set to 'qlmanage' (x86_64).
    (lldbinit) settings set -- target.run-args  "-t" "poc_toc_offset.usdc" "-o" "./"
    (lldbinit) r
    Process 59980 launched: '/usr/bin/qlmanage' (x86_64)
    Testing Quick Look thumbnails with files:
        poc_toc_offset.usdc
    2020-06-23 18:59:28.405728-0500 qlmanage[59980:11301935] [General] Disabling connection to window server
    2020-06-23 18:59:28.406581-0500 qlmanage[59980:11301935] [General] Number of mach ports: 42
    2020-06-23 18:59:28.408263-0500 qlmanage[59980:11301959] [General] Cache is disabled (real server: NO - cache enabled: NO)
    2020-06-23 18:59:28.832447-0500 qlmanage[59980:11301959] MessageTracer: Falling back to default whitelist
    -----------------------------------------------------------------------------------------------------------------------[regs]
      RAX: 0xF041414241603141  RBX: 0x00007000060A1350  RBP: 0x00007000060A1250  RSP: 0x00007000060A1210  o d I t s Z a P c
      RDI: 0x00007000060A1290  RSI: 0x00007000060A12B8  RDX: 0x0000000000000000  RCX: 0x0000000000000000  RIP: 0x00007FFF379A6F00
      R8:  0x0000000000000000  R9:  0x0000000000000000  R10: 0x0000000100000000  R11: 0x00006FFF05EB22B8  R12: 0x0000000105822A00
      R13: 0x00007000060A12B8  R14: 0x00007000060A1290  R15: 0x00007FFF8DFD9890
      CS:  002B  FS: 0000  GS: 0000
    -----------------------------------------------------------------------------------------------------------------------[code]
    @ /System/Library/Frameworks/ModelIO.framework/Versions/A/ModelIO:
    ->  0x7fff379a6f00 (0x8d5f00): 4c 8b 38        mov    r15, qword ptr [rax]
        0x7fff379a6f03 (0x8d5f03): 48 83 c0 08     add    rax, 0x8
        0x7fff379a6f07 (0x8d5f07): 49 89 45 08     mov    qword ptr [r13 + 0x8], rax
        0x7fff379a6f0b (0x8d5f0b): 4c 89 f7        mov    rdi, r14
        0x7fff379a6f0e (0x8d5f0e): 4c 89 fe        mov    rsi, r15
        0x7fff379a6f11 (0x8d5f11): e8 72 01 00 00  call   0x7fff379a7088 ; ___lldb_unnamed_symbol87486$$ModelIO
        0x7fff379a6f16 (0x8d5f16): 4d 8b 26        mov    r12, qword ptr [r14]
        0x7fff379a6f19 (0x8d5f19): 49 c1 e7 05     shl    r15, 0x5
    -----------------------------------------------------------------------------------------------------------------------------
    
    Process 59980 stopped
    * thread #7, queue = 'quicklookd.serialgenerator', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
        frame #0: 0x00007fff379a6f00 ModelIO`___lldb_unnamed_symbol87485$$ModelIO + 122
    Target 0: (qlmanage) stopped.
    (lldbinit) bt
    * thread #7, queue = 'quicklookd.serialgenerator', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
      * frame #0: 0x00007fff379a6f00 ModelIO`___lldb_unnamed_symbol87485$$ModelIO + 122
        frame #1: 0x00007fff379944ed ModelIO`___lldb_unnamed_symbol87000$$ModelIO + 273
        frame #2: 0x00007fff379941c3 ModelIO`___lldb_unnamed_symbol86998$$ModelIO + 555
        frame #3: 0x00007fff37993e06 ModelIO`___lldb_unnamed_symbol86997$$ModelIO + 392
        frame #4: 0x00007fff37992ec9 ModelIO`___lldb_unnamed_symbol86984$$ModelIO + 447
        frame #5: 0x00007fff37a8bbf6 ModelIO`___lldb_unnamed_symbol91742$$ModelIO + 242
        frame #6: 0x00007fff37a8bac8 ModelIO`___lldb_unnamed_symbol91741$$ModelIO + 54
        frame #7: 0x00007fff37a39d2f ModelIO`___lldb_unnamed_symbol90729$$ModelIO + 287
    

**Timeline**

2020-07-01 - Vendor Disclosure (notified Pixar and Apple individually)  
2020-07-01 - Vendor (Pixar) acknowledged report  
2020-07-02 - Vendor (Apple) acknowledged report  
2020-07-14 - Talos tested latest beta of macOS Catalina 10.15.6  
2020-08-04 - Talos follow up with Pixar; no response  
2020-09-16 - 2nd follow up with Pixar  
2020-11-12 - Public Release

Discovered by Aleksandar Nikolic of Cisco Talos.

CVE-2020-13495: TALOS-2020-1104 || Cisco Talos Intelligence Group

Zoho ManageEngine ADSelfService Plus before 6122 allows an authenticated user to achieve remote code execution via executable CMD.EXE input in a password field, This only occurs if a certain password sync feature is enabled that uses passwords as script arguments.

Vulnerability details

**Severity**

**High**

**CVE ID**

CVE-2022-28810

**Affected software versions**

Builds 6121 and below

**Fixed version**

Build 6122

**Fixed on**

April 9, 2022

**Details**

CVE-2022-28810 refers to a security vulnerability reported in ManageEngine ADSelfService Plus that could lead to remote command execution when administrators enabled custom scripts for password sync with required providers, and set the passwords to be sent as arguments during the sync process. When performing a password change or reset, an authenticated end-user could exploit this vulnerability by entering a CMD command in the password field, and have it run remotely on the machine the ADSelfService Plus server is installed in.

We have now released ADSelfService Plus build 6122 with the following updates to fix this issue:

*   Only VBScript and PowerShell files are allowed for custom script.
*   All the script will now be stored strictly in the <Installation Directory> /Scripts folder.
*   Newly set passwords are encoded and sent to the script as parameters.
*   Passwords are sent as string literals instead of arguments to avoid unauthorized execution of commands.

**Impact**

An authenticated end-user can execute remote codes on the machine where ADSelfService Plus is installed.

**Steps to upgrade**

Update your ADSelfService Plus instance to 6122 using the service pack.

**Post-upgrade**

After upgrading to build 6122, follow these guidelines, for better security when using custom scripts.

**Acknowledgements**

This issue was reported by Hernan Diaz, Andrew Iwamaye, Dan Kelly, and Jake Baines of Rapid7 via our Zoho Bug Bounty program.

**Request Support**

Need further assistance? Fill this form, and we'll contact you rightaway.

Highlights

**Password self-service**

Free Active Directory users from attending lengthy help desk calls by allowing them to self-service their password resets/ account unlock tasks. Hassle-free password change for Active Directory users with ADSelfService Plus ‘Change Password’ console. 

**One identity with Single sign-on**

Get seamless one-click access to 100+ cloud applications. With enterprise single sign-on, users can access all their cloud applications with their Active Directory credentials. Thanks to ADSelfService Plus! 

**Password Synchronizer**

Synchronize Windows Active Directory user password/account changes across multiple systems, automatically, including Office 365, G Suite, IBM iSeries and more. 

**Password Policy Enforcer**

Ensure strong user passwords that resist various hacking threats with ADSelfService Plus by enforcing Active Directory users to adhere to compliant passwords via displaying password complexity requirements.

**Directory Self-Update & Corporate Search**

Portal that lets Active Directory users update their latest information and a quick search facility to scout for information about peers by using search keys, like contact number, of the personality being searched.

CVE-2022-28810: 2022-28810 - ManageEngine ADSelfService Plus

Google patches a critical flaw in its Chrome browser, bringing its count of zero-day vulnerabilities fixed in 2022 to four.

Google fixed two vulnerabilities in its Chrome web browser as part of an emergency update this week, including a type confusion vulnerability that is already being exploited in the wild.

The type confusion vulnerability (CVE-2022-1364) impacts the JavaScript and WebAssembly engine in the browser. With this kind of flaw, a program will allocate a resource (such as a pointer or object) using one type but will later try to access the resource using an incompatible type. The vulnerability can be exploited to cause the browser to crash, trigger logical errors, or even execute arbitrary code.

"Google is aware that an exploit for CVE-2022-1364 exists in the wild," the company wrote in the alert. Details will be restricted until a majority of users have updated to Chrome version 100.0.4896.127 across the Windows, Linux, and Mac platforms.

The issues also affect other Chromium-based browsers, such as Microsoft Edge, Brave, and Vivaldi.

The second issue that was fixed appears to be related to issues that were uncovered internally. The alert calls it "various fixes from internal audits, fuzzing, and other initiatives."

This is the third emergency update for Chrome in 2022, and the third zero-day vulnerability patched so far this year. In March, Google (along with Microsoft) fixed a critical flaw to the Chromium v8 JavaScript engine (CVE-2022-1096) that was being actively exploited.

Keep up with the latest cybersecurity threats, newly-discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

Subscribe

Google Emergency Update Fixes Chrome Zero-Day

Chemical companies are the latest to be targeted by the well-known North Korean group, which has targeted financial firms, security researchers, and technology companies in the past.

The North Korean-linked Lazarus group sent fake job offers to targets in the chemical sector and information technology firms, which — when opened — install Trojan horse programs to collect information and send it back to the attackers, technology provider Broadcom's security arm Symantec stated in an advisory on April 14.

The attack is part of a long-running campaign — dubbed Operation Dream Job — that sends targets in specific industries malicious Web files disguised as job offers, which when opened attempts to compromise the system. While the current set of attacks focuses on South Korean chemical companies and their IT service providers, other targets have included industries and government agencies in Europe, Asia, and the United States. This campaign marks a shift, as Lazarus in the past targeted the defense, government, and engineering sectors.

The attacks have, at various times, targeted defense contractors, engineering firms, government agencies, and even pharmaceutical companies during the height of the pandemic, says Dick O’Brien, principal intelligence analyst for Symantec's threat-hunting team.

"North Korea-linked attackers have a long history of targeting intellectual property, presumably to assist strategically important engineering or technology projects," he says, adding: "Across all attacks, we’ve seen a range of data theft \[and\] data exfiltration tools deployed on infected computers. We’re assuming that they take what they need before moving on."

Other security and technology firms have also documented Lazarus's involvement in Operation Dream Job, which some researchers track as Operation AppleJeus. In early 2021, the Lazarus group targeted security researchers with similar offers of high-level jobs in the industry. And, earlier this year, the attackers targeted more than 250 individuals working for news media, software vendors, and Internet infrastructure providers, using job offers that appeared to come from Disney, Google, and Oracle, according to Google, which tracked the campaign.

A related campaign targeted cryptocurrency and financial technology and services firms, Adam Weidemann, a researcher with Google's Threat Analysis Group, stated in a late March blog post.

"We suspect that these groups work for the same entity with a shared supply chain, hence the use of the same exploit kit, but each operate with a different mission set and deploy different techniques," he wrote. "It is possible that other North Korean government-backed attackers have access to the same exploit kit."

**Long-Running Campaign  
**The April 14 advisory from Symantec noted that the campaign started at least as early as August 2020, albeit with a different set of targets. While the current campaign targets the chemical sector, campaigns discovered in 2020 had focused on government agencies and defense contractors, the company stated in its advisory.

"Operation Dream Job involves Lazarus using fake job offers as a means of luring victims into clicking on malicious links or opening malicious attachments that eventually lead to the installation of malware used for espionage," the company said.

Symantec's threat team outlined the steps in a successful attack in January 2022, which completed less than four days after the target received the file until the final execution of a program that collected and exfiltrated system data. After the targeted user opened the fake job offer, the attack exploited a vulnerability in one of two software packages, the INISAFE Web EX Client for system management or MagicLine, a gym management program, says Symantec's O'Brien.

"They’re not household names for us but our working assumption is they’re widely used in the industry or sector they’re currently targeting," he says. "An alternative hypothesis is they installed the software themselves in order to inject into it, but we haven’t seen any evidence of that."

While companies not running either application may not have to worry about this particular attack, cyber-espionage groups such as Lazarus are very good at tailoring attacks to match their target's environment, he says.

For that reason, no single solution will help prevent cyber-espionage attacks, O'Brien stressed. Instead, companies should take a layered approach to defense, using network detection, endpoint security, and hardening technologies — such as multifactor authentication — to protect against multiple vectors of attack, he says.

"We’d also advise implementing proper audit and control of administrative account usage, \[and\] you could also introduce one-time credentials for administrative work to help prevent theft and misuse of admin credentials," O'Brien says. "We’d also suggest creating profiles of usage for admin tools, \[because\] many of these tools are used by attackers to move laterally undetected through a network."

Lazarus Targets Chemical Sector With 'Dream Jobs,' Then Trojans

Omdia Senior Analyst Hollie Hennessy says the new threat to multiple ICS and SCADA devices underscores the importance of a rapid response to IoT and OT security risks.

On April 13, the Department of Energy (DoE), the Cybersecurity and Infrastructure Security Agency (CISA), the National Security Agency (NSA), and the Federal Bureau of Investigation (FBI) released a joint Cybersecurity Advisory to warn that certain industrial control systems (ICS) and supervisory control and data acquisition (SCADA) devices can be targeted by advanced persistent threat (APT) actors who have the capability to gain full system access.

The alert warned that vulnerable products include Schneider Electric programmable logic controllers, OMRON Sysmac NEX PLCs and Open Platform Communications Unified Architecture (OPC UA) servers.

Once on the operational technology (OT) network, APT actors can utilize certain custom-made tools to scan for vulnerable devices, and then exploit and subsequently take control of them.

The advisory also noted a critical issue with Windows-based engineering workstations. Systems in the OT environment, or even on the IT side, can be compromised using an exploit targeting vulnerable motherboard drivers.

Utilizing these techniques, importantly and worryingly, could allow APT actors to elevate their privileges, move laterally within the OT environment to other devices, and disrupt or crash critical devices.

With recent events, such as the Colonial Pipeline attack, which saw the entire OT environment shut down (despite not even originating with OT devices), plus the rise of ransomware and the threat of politically motivated national state actors, those in critical national infrastructure need to act fast.

DoE, CISA, NSA, and the FBI urge organizations, especially those in the energy sector, to implement detection and mitigation recommendations to detect APT activity and harden their ICS/SCADA devices.

The advisory credited security firms including Dragos, Mandiant, and Palo Alto Networks for contributions leading to the advisory. Dragos revealed it’s been analyzing the malware (dubbed PIPEDREAM) since early 2022.

**Conclusions  
**It goes without saying that threat actors will continually find a way to penetrate IoT and OT networks; this advisory is not the first of its kind, nor will it be the last.

The tricky issue with OT networks is their average age (often spanning decades), complex history (evolving organically with minimal planning), and the demanding nature of devices. Traditionally, OT environments did not connect to the IT network in the way they do today — they were physically segregated and disconnected from the outside world, as well as the enterprise and any IT-related functions. This is what’s called an "air gap" but is now a thing of the past.

Digital transformation and the connection of OT systems and other devices to the network broadens the attack surface and opens up industrial environments to attackers. But the business priorities driving this transition, plus the nature of legacy systems and devices that need to be constantly available, mean security is often left behind.

The alert underscores how important it is for enterprises to prepare to address these kinds of IoT and OT security advisories quickly and thoroughly, before adversaries can take advantage of them.

It may seem trivial, but first points of call include changing all passwords and maintaining offline backups — which can help to mitigate brute-force attacks and aid fast recovery in the event of an attack. Those in industrial environments need to ensure they have a robust cybersecurity posture in place — including adequate visibility and monitoring, alongside perimeter and access controls.

The alert notes the importance of collaboration between stakeholders across IT, cybersecurity and operations, which is especially important to ensure cybersecurity is effectively applied in these complex IoT and OT environments with their own unique requirements.

Tag

#mac