I would recommend using the .jar version of this tool on GitHub:
https://github.com/logpresso/CVE-2021-44228-Scanner It will report the relevant
version of log4j in use e.g $ Found CVE-2021-44228 vulnerability in
/usr/lpp/bcp/blsjdpfd.jar, log4j 2.14.0
Jim
On Tue, 14 Dec 2021 13:59:06 -0600,
As Yogi Berra said, "It ain't over till it's over."
https://www.lunasec.io/docs/blog/log4j-zero-day-update-on-cve-2021-45046/
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to
On Tue, 14 Dec 2021 00:23:21 -0500, Cheryl Watson
wrote:
>Hi all,
>
>SAS uses Java and has issued a blog post. Many SAS products use Java and are
>susceptible to this exposure. Each site should ensure that all SAS users and
>the Security staff are made aware of this. Please see their post
On Tue, 14 Dec 2021 10:19:08 -0600, Dave Jousma wrote:
>
>you bring up a good point. there are hits for this in base JAVA V8 both 31bit
>and 64bit, so consequently, any JAVA based app could be using, without
>actually including their own copy of log4j. That also means that the local
DU
Subject: [EXTERNAL] Re: New Java vulnerability
On 12/12/21 6:37 am, Attila Fogarasi wrote:
> not so difficult on z/OS (and there is log4j usage on z/OS but unclear
> that RCE can do much harm on a properly secured z/OS system -- this
> will vary by what application is using the log4j
Itschak wrote:
> I agree. However, the reason we offer such scan is that there other vendor
>products installed in uss. It is not ibm only issue. The second one is
>attitude. Remember the days of Spectre? Ibm never admitted they have it
>until they had a solution and clients was unsure if they
On Tue, 14 Dec 2021 10:38:43 -0500, Phil Smith III wrote:
>Making things even more confusing, there are lots of ways to use log4j, only
>some of which expose this vulnerability. For example, Splunk uses it, but
>says the exploit matters on "All supported non-Windows versions of 8.1.x and
>8.2.x
Phil,
I agree. However, the reason we offer such scan is that there other vendor
products installed in uss. It is not ibm only issue. The second one is
attitude. Remember the days of Spectre? Ibm never admitted they have it
until they had a solution and clients was unsure if they are in risk or
Making things even more confusing, there are lots of ways to use log4j, only
some of which expose this vulnerability. For example, Splunk uses it, but
says the exploit matters on "All supported non-Windows versions of 8.1.x and
8.2.x only if Hadoop (Hunk) and/or DFS are used."
It appears that
There is a IBM webinar spinning up for 12/15
IBM Security is hosting a client webinar about Log4Shell on Wednesday, December
15, 11 a.m. ET. Our X-Force team will review the implications of Log4Shell, who
may be impacted, and steps clients can take to protect themselves today and in
the
N@LISTSERV.UA.EDU
> Subject: Re: New Java vulnerability
>
> wt., 14 gru 2021 o 16:23 Cheryl Watson
> napisał(a):
>
> >
> > Does IBM have anything to say about this? I assume it's on their
> > security portal.
> >
>
>
> https://www.ibm.com/blogs/psi
Hi s1m0n,
Thanks so much!
Cheryl
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Filip Palian
Sent: Tuesday, December 14, 2021 12:26 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: New Java vulnerability
wt., 14 gru 2021 o 16:23 Cheryl Watson napisał(a):
>
>
ason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
David Crayford [dcrayf...@gmail.com]
Sent: Tuesday, December 14, 2021 1:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: New Java vulnerability
On 14/12/21 12:12 pm, Andrew Rowley wr
wt., 14 gru 2021 o 15:12 Andrew Rowley
napisał(a):
> On 14/12/2021 12:30 am, Filip Palian wrote:
> > My intention was to share information about the vulnerabilities affecting
> > Java language. (Without performing a proper comparison) I'd prefer not to
> > get into discussion about one language
On 14/12/21 12:12 pm, Andrew Rowley wrote:
On 14/12/2021 12:30 am, Filip Palian wrote:
My intention was to share information about the vulnerabilities
affecting
Java language. (Without performing a proper comparison) I'd prefer
not to
get into discussion about one language being less secure
wt., 14 gru 2021 o 16:23 Cheryl Watson napisał(a):
>
> Does IBM have anything to say about this? I assume it's on their security
> portal.
>
https://www.ibm.com/blogs/psirt/an-update-on-the-apache-log4j-cve-2021-44228-vulnerability/
Cheers,
s1m0n
Hi all,
Does IBM have anything to say about this? I assume it's on their security
portal.
SAS uses Java and has issued a blog post. Many SAS products use Java and are
susceptible to this exposure. Each site should ensure that all SAS users and
the Security staff are made aware of this.
On 14/12/2021 12:30 am, Filip Palian wrote:
My intention was to share information about the vulnerabilities affecting
Java language. (Without performing a proper comparison) I'd prefer not to
get into discussion about one language being less secure than another.
"Java is insecure" is an implicit
IMHO, it's both.
In general, we've seen articles where some extremely basic npm package gets
'owned', raising the question of, 'why are we using a package to find leap
years' or some such.
So unnecessary package/library dependency is one.
Of course, the naive response to it is to keep a
On 14/12/2021 12:04 am, John McKown wrote:
I don't think COBOL is explicitly, or implicitly, more secure than the base
Java language. The "problem" is not the Java language, but the Internet
infrastructure built into the Java libraries and "add on" facilities such
as LOG4J. A COBOL programmer
wt., 14 gru 2021 o 02:23 Seymour J Metz napisał(a):
> The packages in open repositories for languages like Java and Perl have
> many eyes examinging them, even if there are no official bodies certifying
> them.
>
Correct. There's Internet bug bounty, independent enthusiasts, Google
project
Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Seymour J Metz
Sent: Monday, December 13, 2021 7:24 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: New Java vulnerability
The packages in open repositories for languages like Java and Perl have many
eyes examinging
[john.archie.mck...@gmail.com]
Sent: Monday, December 13, 2021 8:04 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: New Java vulnerability
On Mon, Dec 13, 2021 at 6:14 AM Andrew Rowley
wrote:
> On 13/12/2021 10:52 pm, Filip Palian wrote:
> > @Andrew Rowley, you may want to check this outstanding work
wt., 14 gru 2021 o 00:04 John McKown
napisał(a):
> I don't think COBOL is explicitly, or implicitly, more secure than the base
> Java language. The "problem" is not the Java language, but the Internet
> infrastructure built into the Java libraries and "add on" facilities such
> as LOG4J. A COBOL
pon., 13 gru 2021 o 23:14 Andrew Rowley
napisał(a):
> On 13/12/2021 10:52 pm, Filip Palian wrote:
> > @Andrew Rowley, you may want to check this outstanding work from Adam
> > Gowdiak (search for "ibm java" or "oracle java" or simply check it all):
> >
On Mon, Dec 13, 2021 at 6:14 AM Andrew Rowley
wrote:
> On 13/12/2021 10:52 pm, Filip Palian wrote:
> > @Andrew Rowley, you may want to check this outstanding work from Adam
> > Gowdiak (search for "ibm java" or "oracle java" or simply check it all):
> >
On 13/12/2021 10:52 pm, Filip Palian wrote:
@Andrew Rowley, you may want to check this outstanding work from Adam
Gowdiak (search for "ibm java" or "oracle java" or simply check it all):
https://packetstormsecurity.com/files/author/3682/
You might have to spell it out for me because I can't
pon., 13 gru 2021 o 22:33 Andrew Rowley
napisał(a):
> On 13/12/2021 9:03 pm, David Crayford wrote:
> >
> > Agreed. Although Java itself does have security vulnerabilities and
> > patches are released frequently. It's critical to stay up to date with
> > service
> >
On 13/12/2021 9:03 pm, David Crayford wrote:
Agreed. Although Java itself does have security vulnerabilities and
patches are released frequently. It's critical to stay up to date with
service
https://www.ibm.com/support/pages/java-sdk-security-vulnerabilities
It does, but most of them seem
On 13/12/21 6:57 am, Andrew Rowley wrote:
On 12/12/2021 1:20 pm, David Crayford wrote:
Fingers crossed! The truth is almost no mainframe network (worth its
salt) is visible to outside world. But that doesn't stop the public
servers being compromised.
A quick fix if you are unable to update
On Sun, 12 Dec 2021 17:41:05 -0600, John McKown wrote:
>On Sunday, December 12, 2021, Andrew Rowley wrote:
>>
>> *My understanding* is that the vulnerability can be exploited if you log
>> data that comes from untrusted sources, e.g. user input like URLs, ...
>>
>> Conceptually it seems similar
On Sunday, December 12, 2021, Andrew Rowley
wrote:
> On 12/12/2021 1:20 pm, David Crayford wrote:
>
>> Fingers crossed! The truth is almost no mainframe network (worth its
>> salt) is visible to outside world. But that doesn't stop the public servers
>> being compromised.
>>
>> A quick fix if
On 12/12/2021 1:20 pm, David Crayford wrote:
Fingers crossed! The truth is almost no mainframe network (worth its
salt) is visible to outside world. But that doesn't stop the public
servers being compromised.
A quick fix if you are unable to update to the patched version is to
use the
On 12/12/21 6:37 am, Attila Fogarasi wrote:
not so difficult on z/OS (and there is log4j usage on
z/OS but unclear that RCE can do much harm on a properly secured z/OS
system -- this will vary by what application is using the log4j library).
Fingers crossed! The truth is almost no mainframe
For those curious, log4j is widely used for logging application errors,
hence why it is so widespread. Apache has already released a fix (and
several alternatives to mitigate the effect), see
https://logging.apache.org/log4j/2.x/security.html ... Very serious
vulnerability as it allows Remote
It’s a stinker and it’s going to affect 10s of millions applications.
> On 12 Dec 2021, at 00:24, Jousma, David
> <01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote:
>
> Looks like a bad one...
>
>
> https://www.lunasec.io/docs/blog/log4j-zero-day/
>
>
>
> Dave Jousma
>
> Vice
Looks like a bad one...
https://www.lunasec.io/docs/blog/log4j-zero-day/
Dave Jousma
Vice President | Director, Technology Engineering
Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI
49546
616.653.8429
This e-mail transmission contains information that
37 matches
Mail list logo
