Re: Fwd: Log4j hearing: 'Open source is not the problem'

2022-02-15 Thread David Crayford

On 16/2/22 4:04 am, Radoslaw Skorupka wrote:

W dniu 14.02.2022 o 20:58, David Crayford pisze:

On 15/2/22 3:48 am, Phil Smith III wrote:
While clearly closed source is no more likely to be randomly secure 
than

open source, the fact that the source is available for open source (by
definition!) does perhaps change the equation a bit. The question I 
have

ZERO data to answer is:


If a hacker has access to the binary, they essentially have the code. 
For example, give me Java Jar and I can use any number of Java 
decompilers [1] (including my IDE) to recreate the source code 
verbatim. Same for
C#. C/C++ not so easy but yet again there are decompilers, but you 
lose the original symbol/label names. Most hackers just fire up a 
debugger and look at the assembly. Assembly code is no brainer.


Of course, code leaks are common. The entire Windows XP code base was 
leaked. By that time it was old but a huge amount of customers, 
including the military, were still using it. Now a lot of companies 
are all moving to
Git they better make sure they have locked down the repository host 
servers. And if they're using Github or another cloud based 
repository service then fingers crossed it never gets breached.


[1] https://github.com/deathmarine/Luyten



My €0.02:
1. Source code (open source) is *NOT* the same as decompilation.


For Java and C# it is. I can step through the Java JRE in a debugger and 
it recreates the source code verbatim, variable names etc. The only 
thing missing is comments and I could care less about that.



2. An access to source code is better than no access - from 
vulnerability searching point of view.


The horse bolted a long time ago. Even Microsoft have open sourced huge 
amounts of their ecosystem. C#, .Net, PowerShell etc are all hosted on 
Github. Microsoft owns Github, how about that for a paradigm shift?



3. However there are notable holes found years after the code was 
released.
4. Open source mean more eyes are looking for the holes => better code 
review. However closed source means it is less likely that possible 
hole would be found. What's better?
5. While open source means access to the source code it does not mean 
code contribution. Let's assume I made some piece of software and used 
log4j. What next?


In the case of Log4j it's a moot point. The use of JNDI was documented 
in the manual. Having access to the source code is irrelevant.








--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: Fwd: Log4j hearing: 'Open source is not the problem'

2022-02-15 Thread Radoslaw Skorupka

W dniu 14.02.2022 o 20:58, David Crayford pisze:

On 15/2/22 3:48 am, Phil Smith III wrote:

While clearly closed source is no more likely to be randomly secure than
open source, the fact that the source is available for open source (by
definition!) does perhaps change the equation a bit. The question I have
ZERO data to answer is:


If a hacker has access to the binary, they essentially have the code. 
For example, give me Java Jar and I can use any number of Java 
decompilers [1] (including my IDE) to recreate the source code 
verbatim. Same for
C#. C/C++ not so easy but yet again there are decompilers, but you 
lose the original symbol/label names. Most hackers just fire up a 
debugger and look at the assembly. Assembly code is no brainer.


Of course, code leaks are common. The entire Windows XP code base was 
leaked. By that time it was old but a huge amount of customers, 
including the military, were still using it. Now a lot of companies 
are all moving to
Git they better make sure they have locked down the repository host 
servers. And if they're using Github or another cloud based repository 
service then fingers crossed it never gets breached.


[1] https://github.com/deathmarine/Luyten



My €0.02:
1. Source code (open source) is *NOT* the same as decompilation.
2. An access to source code is better than no access - from 
vulnerability searching point of view.

3. However there are notable holes found years after the code was released.
4. Open source mean more eyes are looking for the holes => better code 
review. However closed source means it is less likely that possible hole 
would be found. What's better?
5. While open source means access to the source code it does not mean 
code contribution. Let's assume I made some piece of software and used 
log4j. What next?



--
Radoslaw Skorupka
Lodz, Poland

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: [EXTERNAL] Re: Fwd: Log4j hearing: 'Open source is not the problem'

2022-02-14 Thread Dave Barry
I'm old enough to remember reading the source code for VM on microfiche.  
Eventually, IBM got smart and went with OCO.



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: Fwd: Log4j hearing: 'Open source is not the problem'

2022-02-14 Thread David Crayford

On 15/2/22 3:48 am, Phil Smith III wrote:

While clearly closed source is no more likely to be randomly secure than
open source, the fact that the source is available for open source (by
definition!) does perhaps change the equation a bit. The question I have
ZERO data to answer is:


If a hacker has access to the binary, they essentially have the code. 
For example, give me Java Jar and I can use any number of Java 
decompilers [1] (including my IDE) to recreate the source code verbatim. 
Same for
C#. C/C++ not so easy but yet again there are decompilers, but you lose 
the original symbol/label names. Most hackers just fire up a debugger 
and look at the assembly. Assembly code is no brainer.


Of course, code leaks are common. The entire Windows XP code base was 
leaked. By that time it was old but a huge amount of customers, 
including the military, were still using it. Now a lot of companies are 
all moving to
Git they better make sure they have locked down the repository host 
servers. And if they're using Github or another cloud based repository 
service then fingers crossed it never gets breached.


[1] https://github.com/deathmarine/Luyten


  


Are more vulnerabilities found by attacking the executing code, or by
examining the source and finding holes?

  


I'd be unsurprised to find either that there is extensive research on this,
or that nobody has analyzed it at all.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Fwd: Log4j hearing: 'Open source is not the problem'

2022-02-14 Thread Phil Smith III
While clearly closed source is no more likely to be randomly secure than
open source, the fact that the source is available for open source (by
definition!) does perhaps change the equation a bit. The question I have
ZERO data to answer is:

 

Are more vulnerabilities found by attacking the executing code, or by
examining the source and finding holes?

 

I'd be unsurprised to find either that there is extensive research on this,
or that nobody has analyzed it at all.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: Fwd: Log4j hearing: 'Open source is not the problem'

2022-02-13 Thread Tom Brennan
With log4j there's a public blog page with two lists:  #1 shows products 
not affected, and #2 shows products remediated (with links to more info).


If something is not in either list, that could mean it's still being 
evaluated, or (more likely?) in the category you mentioned - never 
published publicly.  In that case the Security Portal is the only way to 
get further direct information.  How to get vetted for that I have no 
idea.  I've tried a couple of times with no luck - not even a reply. 
Maybe it's like the Masons, "...each candidate must be free and of good 
repute".


https://www.ibm.com/blogs/psirt/an-update-on-the-apache-log4j-cve-2021-44228-vulnerability/

On 2/13/2022 7:30 AM, Ed Jaffe wrote:

On 2/13/2022 7:18 AM, Seymour J Metz wrote:
The (somewhat simplified) way that IBM handles this for z/OS is via 
hold data and customer notification of security fixes. IMHO that works 
well.


Disclosed to customers only via a secure channel that limits exposure to 
a select list of vetted employees with a need to know.


Never published publicly in any way, shape or form.




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: Fwd: Log4j hearing: 'Open source is not the problem'

2022-02-13 Thread Ed Jaffe

On 2/13/2022 7:18 AM, Seymour J Metz wrote:

The (somewhat simplified) way that IBM handles this for z/OS is via hold data 
and customer notification of security fixes. IMHO that works well.


Disclosed to customers only via a secure channel that limits exposure to 
a select list of vetted employees with a need to know.


Never published publicly in any way, shape or form.


--
Phoenix Software International
Edward E. Jaffe
Chief Technology Officer
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: Fwd: Log4j hearing: 'Open source is not the problem'

2022-02-13 Thread Seymour J Metz
As opposed to helping the criminals to attack him before he has time to develop 
and test that protection? All options are bad: the issue is which is least bad, 
and going for the least bad option *is* responsible.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Itschak Mugzach [0305158ad67d-dmarc-requ...@listserv.ua.edu]
Sent: Sunday, February 13, 2022 2:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Log4j hearing: 'Open source is not the problem'

very responsible. Meanwhile, the client is open for attacks. However, he
can't protect himself since no one reported it affects his MF.

בתאריך יום א׳, 13 בפבר׳ 2022 ב-3:42 מאת Seymour J Metz :

> I believe that developing a fix before you disclose the vulnerability is
> the responsible thing to do.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of David Crayford [dcrayf...@gmail.com]
> Sent: Saturday, February 12, 2022 6:17 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Fwd: Log4j hearing: 'Open source is not the problem'
>
> On 13/2/22 3:38 am, Itschak Mugzach wrote:
> > If someone develops code that is vulnerable, only the organization he
> works
> > for is (potentially) affected and the attacker does not have access to
> the
> > code to play with. With open source, the code is accessible to everyone,
> > and the problem hits millions of organizations.
>
> Are you sure the attacker doesn't have the code? A huge percentage of
> hacks come from insider threats. In the case of Solar Winds the attackers
> had the code and access to the build pipeline.
>
>
> >
> > The problem is not the vendor that makes use of open source, it is the
> fact
> > that when the vulnerability is discovered, there is a time window until
> it
> > is patched. And this is only if it was discovered by an ethical bug
> hunter.
>
> Log4Shell was discovered by a security researcher at Ali-Baba.
> Shellshock, Heartbleed, Meltdown etc were discovered by security
> researchers at Google.
> The difference with IBM or companies is that they don't disclose
> vulnerabilities. You probably think that's a good idea. In truth, if
> those vulnerabilities are there, especially
> on public facing networks there is just as much chance of a breach.
>
>
> >
> > This is why I am not impressed (but do appreciate the effort) by the
> tools
> > David and his company uses. They do their best,
>
> They do find vulnerabilities. They are amazingly smart and can detect
> when you open a secure TCP connection and don't authenticate the
> hostname which could result in a MITM attack. That could be considered
> a 0-day.
>
>
> > but it will not help in
> > case of a zero date and the scale of an open source vulnerability is
> > unlimited compared to a specific local code, bad as it is.
>
> What about the scale of a vendor product, such as IBM Data Risk Manager?
> A security research found 4 0-days and a sackful of other
> vulnerabilities and IBM refused to accept the report until
> the researcher went public. IBMs customers are enterprises such as banks
> and insurance companies.
>
>
> https://www.ibm.com/support/pages/security-bulletin-ibm-data-risk-manager-affected-multiple-vulnerabilities-4
>
> The security researcher in this video
> https://www.youtube.com/watch?v=q8mFhDmBEIc claims to have found > 10
> 0-days on z/OS by exploiting buffer overflows in APF-authorized C programs
> by overlaying R14 with his exploit code. I can't verify the veracity of
> this claim but it seems plausible. It's the same technique used in the
> Logica breach. Last time you scoffed at that and asked
> if there had been a breach. So I guess that 0-days are acceptable unless
> there has been a breach, or did I misunderstand you?
>
>
> >
> > The funny thing is that although millions of eyes look at "open source"
> (as
> > Chrles mentioned) they rarely find the vulnerability in a very
> > common, highly used code (such as log4jv2 that has been here since
> > 2012...).
> >
> > Saying that, open source is here to stay. Just don't wait for the vendor
> to
> > report on vulnerabilities. Scan it yourself frequently.
> >
> > My two israeli shekels cents (Actually called "agorot").
> >
> > ITschak
> >
> > *| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere
> > Platform* *|* *Information Security Continuous Monitoring for Z/OS,
> zLinux
> > and 

Re: Fwd: Log4j hearing: 'Open source is not the problem'

2022-02-13 Thread Seymour J Metz
If the vulnerability has been there for a long time, delaying the information 
for a few months and then fixing it will be less of a risk then publishing the 
details immediately. If it's a new vulnerability, the responsible thing to do 
is to publish the fact that there is a vulnerability in that update.

The (somewhat simplified) way that IBM handles this for z/OS is via hold data 
and customer notification of security fixes. IMHO that works well.

Mind you, keeping details secret is a holding action pending development and 
testing of a fix; it is in no way an excuse for not making a fix available ASAP.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Bob 
Bridges [robhbrid...@gmail.com]
Sent: Sunday, February 13, 2022 8:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Log4j hearing: 'Open source is not the problem'

This is the old problem:  Do you publicize what the problems are, so that the 
bad guys will find out?  Or do you not detail the vulnerabilities, so that the 
good guys don't know how to protect themselves?

I come down on Cliff Stoll's side.  The bad guys out there already know; in his 
book he gives the details so the good guys can fix the problems.  One might 
think "only SOME of the bad guys know; do we want them ALL to know?".  But the 
bad guys are telling each other where the holes are.  And since our work is 
defensive, not offensive, it doesn't matter whether there are a thousand bad 
guys who know the factory-default password, or only a hundred; all it takes is 
one and I'm vulnerable if I don't change it.

So on the whole, I'm in favor of publishing the holes.  I suppose if a fix can 
be implemented in a day or two, it might make sense to hold off that long.  But 
if it's a matter of a week, I think publishing is better.  That’s my vote, 
anyway.

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* Shoveling the driveway before it has stopped snowing is like cleaning your 
house before your kids are grown. */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Itschak Mugzach
Sent: Sunday, February 13, 2022 02:23

very responsible. Meanwhile, the client is open for attacks. However, he can't 
protect himself since no one reported it affects his MF.

--- בתאריך יום א׳, 13 בפבר׳ 2022 ב-3:42 מאת Seymour J Metz :
> I believe that developing a fix before you disclose the vulnerability
> is the responsible thing to do.
>
> 
> From: David Crayford [dcrayf...@gmail.com]
> Sent: Saturday, February 12, 2022 6:17 PM
>
> Are you sure the attacker doesn't have the code? A huge percentage of
> hacks come from insider threats. In the case of Solar Winds the
> attackers had the code and access to the build pipeline.
>
> --- On 13/2/22 3:38 am, Itschak Mugzach wrote:
> > If someone develops code that is vulnerable, only the organization
> > he works for is (potentially) affected and the attacker does not
> > have access to the code to play with. With open source, the code is
> > accessible to everyone, and the problem hits millions of
> > organizations.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: Fwd: Log4j hearing: 'Open source is not the problem'

2022-02-13 Thread Itschak Mugzach
+1 for Bob.

I don't know who knows what. The bad guys do not check what you have, they
try their tools and ce sera sera.

Best,
ITschak

*| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere
Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux
and IBM I **|  *

*|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|*
*Skype**: ItschakMugzach **|* *Web**: www.Securiteam.co.il  **|*





On Sun, Feb 13, 2022 at 3:19 PM Bob Bridges  wrote:

> This is the old problem:  Do you publicize what the problems are, so that
> the bad guys will find out?  Or do you not detail the vulnerabilities, so
> that the good guys don't know how to protect themselves?
>
> I come down on Cliff Stoll's side.  The bad guys out there already know;
> in his book he gives the details so the good guys can fix the problems.
> One might think "only SOME of the bad guys know; do we want them ALL to
> know?".  But the bad guys are telling each other where the holes are.  And
> since our work is defensive, not offensive, it doesn't matter whether there
> are a thousand bad guys who know the factory-default password, or only a
> hundred; all it takes is one and I'm vulnerable if I don't change it.
>
> So on the whole, I'm in favor of publishing the holes.  I suppose if a fix
> can be implemented in a day or two, it might make sense to hold off that
> long.  But if it's a matter of a week, I think publishing is better.
> That’s my vote, anyway.
>
> ---
> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>
> /* Shoveling the driveway before it has stopped snowing is like cleaning
> your house before your kids are grown. */
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Itschak Mugzach
> Sent: Sunday, February 13, 2022 02:23
>
> very responsible. Meanwhile, the client is open for attacks. However, he
> can't protect himself since no one reported it affects his MF.
>
> --- בתאריך יום א׳, 13 בפבר׳ 2022 ב-3:42 מאת Seymour J Metz  >:
> > I believe that developing a fix before you disclose the vulnerability
> > is the responsible thing to do.
> >
> > 
> > From: David Crayford [dcrayf...@gmail.com]
> > Sent: Saturday, February 12, 2022 6:17 PM
> >
> > Are you sure the attacker doesn't have the code? A huge percentage of
> > hacks come from insider threats. In the case of Solar Winds the
> > attackers had the code and access to the build pipeline.
> >
> > --- On 13/2/22 3:38 am, Itschak Mugzach wrote:
> > > If someone develops code that is vulnerable, only the organization
> > > he works for is (potentially) affected and the attacker does not
> > > have access to the code to play with. With open source, the code is
> > > accessible to everyone, and the problem hits millions of
> > > organizations.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: Fwd: Log4j hearing: 'Open source is not the problem'

2022-02-13 Thread Bob Bridges
This is the old problem:  Do you publicize what the problems are, so that the 
bad guys will find out?  Or do you not detail the vulnerabilities, so that the 
good guys don't know how to protect themselves?

I come down on Cliff Stoll's side.  The bad guys out there already know; in his 
book he gives the details so the good guys can fix the problems.  One might 
think "only SOME of the bad guys know; do we want them ALL to know?".  But the 
bad guys are telling each other where the holes are.  And since our work is 
defensive, not offensive, it doesn't matter whether there are a thousand bad 
guys who know the factory-default password, or only a hundred; all it takes is 
one and I'm vulnerable if I don't change it.

So on the whole, I'm in favor of publishing the holes.  I suppose if a fix can 
be implemented in a day or two, it might make sense to hold off that long.  But 
if it's a matter of a week, I think publishing is better.  That’s my vote, 
anyway.

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* Shoveling the driveway before it has stopped snowing is like cleaning your 
house before your kids are grown. */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Itschak Mugzach
Sent: Sunday, February 13, 2022 02:23

very responsible. Meanwhile, the client is open for attacks. However, he can't 
protect himself since no one reported it affects his MF.

--- בתאריך יום א׳, 13 בפבר׳ 2022 ב-3:42 מאת Seymour J Metz :
> I believe that developing a fix before you disclose the vulnerability 
> is the responsible thing to do.
>
> 
> From: David Crayford [dcrayf...@gmail.com]
> Sent: Saturday, February 12, 2022 6:17 PM
>
> Are you sure the attacker doesn't have the code? A huge percentage of 
> hacks come from insider threats. In the case of Solar Winds the 
> attackers had the code and access to the build pipeline.
>
> --- On 13/2/22 3:38 am, Itschak Mugzach wrote:
> > If someone develops code that is vulnerable, only the organization 
> > he works for is (potentially) affected and the attacker does not
> > have access to the code to play with. With open source, the code is
> > accessible to everyone, and the problem hits millions of
> > organizations.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: Fwd: Log4j hearing: 'Open source is not the problem'

2022-02-12 Thread Itschak Mugzach
very responsible. Meanwhile, the client is open for attacks. However, he
can't protect himself since no one reported it affects his MF.

בתאריך יום א׳, 13 בפבר׳ 2022 ב-3:42 מאת Seymour J Metz :

> I believe that developing a fix before you disclose the vulnerability is
> the responsible thing to do.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of David Crayford [dcrayf...@gmail.com]
> Sent: Saturday, February 12, 2022 6:17 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Fwd: Log4j hearing: 'Open source is not the problem'
>
> On 13/2/22 3:38 am, Itschak Mugzach wrote:
> > If someone develops code that is vulnerable, only the organization he
> works
> > for is (potentially) affected and the attacker does not have access to
> the
> > code to play with. With open source, the code is accessible to everyone,
> > and the problem hits millions of organizations.
>
> Are you sure the attacker doesn't have the code? A huge percentage of
> hacks come from insider threats. In the case of Solar Winds the attackers
> had the code and access to the build pipeline.
>
>
> >
> > The problem is not the vendor that makes use of open source, it is the
> fact
> > that when the vulnerability is discovered, there is a time window until
> it
> > is patched. And this is only if it was discovered by an ethical bug
> hunter.
>
> Log4Shell was discovered by a security researcher at Ali-Baba.
> Shellshock, Heartbleed, Meltdown etc were discovered by security
> researchers at Google.
> The difference with IBM or companies is that they don't disclose
> vulnerabilities. You probably think that's a good idea. In truth, if
> those vulnerabilities are there, especially
> on public facing networks there is just as much chance of a breach.
>
>
> >
> > This is why I am not impressed (but do appreciate the effort) by the
> tools
> > David and his company uses. They do their best,
>
> They do find vulnerabilities. They are amazingly smart and can detect
> when you open a secure TCP connection and don't authenticate the
> hostname which could result in a MITM attack. That could be considered
> a 0-day.
>
>
> > but it will not help in
> > case of a zero date and the scale of an open source vulnerability is
> > unlimited compared to a specific local code, bad as it is.
>
> What about the scale of a vendor product, such as IBM Data Risk Manager?
> A security research found 4 0-days and a sackful of other
> vulnerabilities and IBM refused to accept the report until
> the researcher went public. IBMs customers are enterprises such as banks
> and insurance companies.
>
>
> https://www.ibm.com/support/pages/security-bulletin-ibm-data-risk-manager-affected-multiple-vulnerabilities-4
>
> The security researcher in this video
> https://www.youtube.com/watch?v=q8mFhDmBEIc claims to have found > 10
> 0-days on z/OS by exploiting buffer overflows in APF-authorized C programs
> by overlaying R14 with his exploit code. I can't verify the veracity of
> this claim but it seems plausible. It's the same technique used in the
> Logica breach. Last time you scoffed at that and asked
> if there had been a breach. So I guess that 0-days are acceptable unless
> there has been a breach, or did I misunderstand you?
>
>
> >
> > The funny thing is that although millions of eyes look at "open source"
> (as
> > Chrles mentioned) they rarely find the vulnerability in a very
> > common, highly used code (such as log4jv2 that has been here since
> > 2012...).
> >
> > Saying that, open source is here to stay. Just don't wait for the vendor
> to
> > report on vulnerabilities. Scan it yourself frequently.
> >
> > My two israeli shekels cents (Actually called "agorot").
> >
> > ITschak
> >
> > *| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere
> > Platform* *|* *Information Security Continuous Monitoring for Z/OS,
> zLinux
> > and IBM I **|  *
> >
> > *|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404
> **|*
> > *Skype**: ItschakMugzach **|* *Web**:
> http://secure-web.cisco.com/1oH69EmxiPM3D-pi2iMI3amWVgRxjlVjSqd5lhVhG7MlHXIO3a9pNfhJfn-tUCZVQcd2Te-X0rG1t8gj0oKs6fUS1UlG-IyF3G2Q79IcTAByERK-1lba3FjVMT0yVQAqALG-S8HF4TEajq2_HlNh_KCHDDApGXFN5-5UK3ycRgY2t8GAxFALp73R55kIfn7fXCwKsIBuC9pMdVeYQsgdSm28BhrHCnLoE3lzSY78wEaji-Vx_tBUnLbHk6P92sGrIiLA23ICrZQFmoXT5wQhKZghc1leKXK5evoTHq88BAgFJ4t5emIO-uWU5d76CXJzaOexwk12RrG2XPL65hQpZESW-jLugueCtN7MGBF5ph2S3wM7WNEk8zbLJ0NJfBCSdJIkx1WWPcAK6d

Re: Fwd: Log4j hearing: 'Open source is not the problem'

2022-02-12 Thread Seymour J Metz
I believe that developing a fix before you disclose the vulnerability is the 
responsible thing to do.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
David Crayford [dcrayf...@gmail.com]
Sent: Saturday, February 12, 2022 6:17 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Log4j hearing: 'Open source is not the problem'

On 13/2/22 3:38 am, Itschak Mugzach wrote:
> If someone develops code that is vulnerable, only the organization he works
> for is (potentially) affected and the attacker does not have access to the
> code to play with. With open source, the code is accessible to everyone,
> and the problem hits millions of organizations.

Are you sure the attacker doesn't have the code? A huge percentage of
hacks come from insider threats. In the case of Solar Winds the attackers
had the code and access to the build pipeline.


>
> The problem is not the vendor that makes use of open source, it is the fact
> that when the vulnerability is discovered, there is a time window until it
> is patched. And this is only if it was discovered by an ethical bug hunter.

Log4Shell was discovered by a security researcher at Ali-Baba.
Shellshock, Heartbleed, Meltdown etc were discovered by security
researchers at Google.
The difference with IBM or companies is that they don't disclose
vulnerabilities. You probably think that's a good idea. In truth, if
those vulnerabilities are there, especially
on public facing networks there is just as much chance of a breach.


>
> This is why I am not impressed (but do appreciate the effort) by the tools
> David and his company uses. They do their best,

They do find vulnerabilities. They are amazingly smart and can detect
when you open a secure TCP connection and don't authenticate the
hostname which could result in a MITM attack. That could be considered
a 0-day.


> but it will not help in
> case of a zero date and the scale of an open source vulnerability is
> unlimited compared to a specific local code, bad as it is.

What about the scale of a vendor product, such as IBM Data Risk Manager?
A security research found 4 0-days and a sackful of other
vulnerabilities and IBM refused to accept the report until
the researcher went public. IBMs customers are enterprises such as banks
and insurance companies.

https://www.ibm.com/support/pages/security-bulletin-ibm-data-risk-manager-affected-multiple-vulnerabilities-4

The security researcher in this video
https://www.youtube.com/watch?v=q8mFhDmBEIc claims to have found > 10
0-days on z/OS by exploiting buffer overflows in APF-authorized C programs
by overlaying R14 with his exploit code. I can't verify the veracity of
this claim but it seems plausible. It's the same technique used in the
Logica breach. Last time you scoffed at that and asked
if there had been a breach. So I guess that 0-days are acceptable unless
there has been a breach, or did I misunderstand you?


>
> The funny thing is that although millions of eyes look at "open source" (as
> Chrles mentioned) they rarely find the vulnerability in a very
> common, highly used code (such as log4jv2 that has been here since
> 2012...).
>
> Saying that, open source is here to stay. Just don't wait for the vendor to
> report on vulnerabilities. Scan it yourself frequently.
>
> My two israeli shekels cents (Actually called "agorot").
>
> ITschak
>
> *| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere
> Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux
> and IBM I **|  *
>
> *|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|*
> *Skype**: ItschakMugzach **|* *Web**: 
> http://secure-web.cisco.com/1oH69EmxiPM3D-pi2iMI3amWVgRxjlVjSqd5lhVhG7MlHXIO3a9pNfhJfn-tUCZVQcd2Te-X0rG1t8gj0oKs6fUS1UlG-IyF3G2Q79IcTAByERK-1lba3FjVMT0yVQAqALG-S8HF4TEajq2_HlNh_KCHDDApGXFN5-5UK3ycRgY2t8GAxFALp73R55kIfn7fXCwKsIBuC9pMdVeYQsgdSm28BhrHCnLoE3lzSY78wEaji-Vx_tBUnLbHk6P92sGrIiLA23ICrZQFmoXT5wQhKZghc1leKXK5evoTHq88BAgFJ4t5emIO-uWU5d76CXJzaOexwk12RrG2XPL65hQpZESW-jLugueCtN7MGBF5ph2S3wM7WNEk8zbLJ0NJfBCSdJIkx1WWPcAK6dsoWIeiASmUmeLRm7U4sZC2ToS65mTdasXOZtkvZSCupvhDgoTj0/http%3A%2F%2Fwww.Securiteam.co.il
>   **|*
>
>
>
>
>
> On Sat, Feb 12, 2022 at 7:04 PM Charles Mills  wrote:
>
>> Nobody asked me, but I think David buried the most important point in the
>> middle. I have seen lots of TERRIBLE code written by "engineers from big
>> tech." That's not the key point. The key point is
>>
>>> the code is in the open and can be scrutinized by millions of people
>> There are thousands (if not millions) of people, ranging from high school
>> code nerds to professional security consulting firms, hoping to make a name
>

Re: Fwd: Log4j hearing: 'Open source is not the problem'

2022-02-12 Thread Seymour J Metz
An awful lot of exploits have been in proprietary software. An awful lot of 
successful cracks have been due to, e.g., insiders, sloppy procedure, social 
engineering, rather than software bugs. The Devil is in the details. What are 
the statistics on root causes?


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Itschak Mugzach [0305158ad67d-dmarc-requ...@listserv.ua.edu]
Sent: Saturday, February 12, 2022 2:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Log4j hearing: 'Open source is not the problem'

If someone develops code that is vulnerable, only the organization he works
for is (potentially) affected and the attacker does not have access to the
code to play with. With open source, the code is accessible to everyone,
and the problem hits millions of organizations.

The problem is not the vendor that makes use of open source, it is the fact
that when the vulnerability is discovered, there is a time window until it
is patched. And this is only if it was discovered by an ethical bug hunter.

This is why I am not impressed (but do appreciate the effort) by the tools
David and his company uses. They do their best, but it will not help in
case of a zero date and the scale of an open source vulnerability is
unlimited compared to a specific local code, bad as it is.

The funny thing is that although millions of eyes look at "open source" (as
Chrles mentioned) they rarely find the vulnerability in a very
common, highly used code (such as log4jv2 that has been here since
2012...).

Saying that, open source is here to stay. Just don't wait for the vendor to
report on vulnerabilities. Scan it yourself frequently.

My two israeli shekels cents (Actually called "agorot").

ITschak

*| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere
Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux
and IBM I **|  *

*|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|*
*Skype**: ItschakMugzach **|* *Web**: 
http://secure-web.cisco.com/1dJc8cUdwjcnxoQy7NK9JjnUODSPv2zhqKTQkRI-fNKDoZVm5IIKlO9GD2-lNJOB-diRJzxyDQoy9eSsDqKa_WtmGtbaXEqYi-nGHXjlxqZTHUPjrJBhiA-c-KNIHvaW00aI1LY-2ufYpF9O2Zz747oQhYyZXU6ABtkRDUKiuO1dxFKWxo1ZSzpYygvw4DjLxa770lOum03Xyez4cUNiF7jjjENfhzBuiPOPh4CAh6Qa9Dk-b0hZRDBty2b3nWjvPcfF2NWCsEoE_npKbns7tyiPCQl-tSxmKLaWK4eCj2NTzyEW4BXGh9RS40_hn2YViX3NfA0CuiJipPVo7zh5Lqd3m4h7va5cH5GSb1gnfN9Jz3GFzqvlwgrRLBQileuEsFxoOGFn3G_IO_eSxMev9-e9VRkoDtMc6WEObHzQiaTuxZugKdxafRSvhtCT8gRvn/http%3A%2F%2Fwww.Securiteam.co.il
  **|*





On Sat, Feb 12, 2022 at 7:04 PM Charles Mills  wrote:

> Nobody asked me, but I think David buried the most important point in the
> middle. I have seen lots of TERRIBLE code written by "engineers from big
> tech." That's not the key point. The key point is
>
> > the code is in the open and can be scrutinized by millions of people
>
> There are thousands (if not millions) of people, ranging from high school
> code nerds to professional security consulting firms, hoping to make a name
> for themselves by being the first to spot some vulnerability in Apache, the
> Linux kernel, etc. That is an incredible free code inspection service. That
> is the key to the security of open source (IMHO).
>
> You can't say that for most in-house software. You all know what corporate
> culture is like. #1 your boss is not paying you to scrutinize other
> peoples' code. And #2 if you spot some flaw in Bob's code you keep your
> head down, because Bob is such a grump and does not take criticism well.
>
> And BTW this is coming from someone (me) who is basically a proprietary
> software guy. I made my money writing conventionally-licensed proprietary
> software. I have never contributed to an open source project.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of David Crayford
> Sent: Friday, February 11, 2022 11:39 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Fwd: Log4j hearing: 'Open source is not the problem'
>
> On 12/2/22 4:56 am, Radoslaw Skorupka wrote:
> > Well, who said it is not a problem???
>
> I do. I maintain that proprietary code has just as many vulnerabilities
> as open source. In fact, I would suggest that open source code is better
> as the standard of engineer tends to be much higher than your average
> Joe coder working for a bank. Also, the code is in the open and can be
> scrutinized by millions of people. Who do you think develops open source
> software? Is it hobbyists, enthusiasts, students, academics etc? The
> truth is it's mostly engineers f

Re: Fwd: Log4j hearing: 'Open source is not the problem'

2022-02-12 Thread David Crayford

On 13/2/22 1:03 am, Charles Mills wrote:

Nobody asked me, but I think David buried the most important point in the middle. I have 
seen lots of TERRIBLE code written by "engineers from big tech." That's not the 
key point. The key point is


the code is in the open and can be scrutinized by millions of people

There are thousands (if not millions) of people, ranging from high school code 
nerds to professional security consulting firms, hoping to make a name for 
themselves by being the first to spot some vulnerability in Apache, the Linux 
kernel, etc. That is an incredible free code inspection service. That is the 
key to the security of open source (IMHO).
It's not just about making a name themselves. It can be incredibly 
lucrative, with some companies willing to pay six figure sums on bug 
bounties https://www.bugcrowd.com/bug-bounty-list/


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: Fwd: Log4j hearing: 'Open source is not the problem'

2022-02-12 Thread David Crayford

On 13/2/22 3:38 am, Itschak Mugzach wrote:

If someone develops code that is vulnerable, only the organization he works
for is (potentially) affected and the attacker does not have access to the
code to play with. With open source, the code is accessible to everyone,
and the problem hits millions of organizations.


Are you sure the attacker doesn't have the code? A huge percentage of 
hacks come from insider threats. In the case of Solar Winds the attackers

had the code and access to the build pipeline.




The problem is not the vendor that makes use of open source, it is the fact
that when the vulnerability is discovered, there is a time window until it
is patched. And this is only if it was discovered by an ethical bug hunter.


Log4Shell was discovered by a security researcher at Ali-Baba. 
Shellshock, Heartbleed, Meltdown etc were discovered by security 
researchers at Google.
The difference with IBM or companies is that they don't disclose 
vulnerabilities. You probably think that's a good idea. In truth, if 
those vulnerabilities are there, especially

on public facing networks there is just as much chance of a breach.




This is why I am not impressed (but do appreciate the effort) by the tools
David and his company uses. They do their best,


They do find vulnerabilities. They are amazingly smart and can detect 
when you open a secure TCP connection and don't authenticate the 
hostname which could result in a MITM attack. That could be considered

a 0-day.



but it will not help in
case of a zero date and the scale of an open source vulnerability is
unlimited compared to a specific local code, bad as it is.


What about the scale of a vendor product, such as IBM Data Risk Manager? 
A security research found 4 0-days and a sackful of other 
vulnerabilities and IBM refused to accept the report until
the researcher went public. IBMs customers are enterprises such as banks 
and insurance companies.


https://www.ibm.com/support/pages/security-bulletin-ibm-data-risk-manager-affected-multiple-vulnerabilities-4

The security researcher in this video 
https://www.youtube.com/watch?v=q8mFhDmBEIc claims to have found > 10 
0-days on z/OS by exploiting buffer overflows in APF-authorized C programs
by overlaying R14 with his exploit code. I can't verify the veracity of 
this claim but it seems plausible. It's the same technique used in the 
Logica breach. Last time you scoffed at that and asked
if there had been a breach. So I guess that 0-days are acceptable unless 
there has been a breach, or did I misunderstand you?





The funny thing is that although millions of eyes look at "open source" (as
Chrles mentioned) they rarely find the vulnerability in a very
common, highly used code (such as log4jv2 that has been here since
2012...).

Saying that, open source is here to stay. Just don't wait for the vendor to
report on vulnerabilities. Scan it yourself frequently.

My two israeli shekels cents (Actually called "agorot").

ITschak

*| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere
Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux
and IBM I **|  *

*|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|*
*Skype**: ItschakMugzach **|* *Web**: www.Securiteam.co.il  **|*





On Sat, Feb 12, 2022 at 7:04 PM Charles Mills  wrote:


Nobody asked me, but I think David buried the most important point in the
middle. I have seen lots of TERRIBLE code written by "engineers from big
tech." That's not the key point. The key point is


the code is in the open and can be scrutinized by millions of people

There are thousands (if not millions) of people, ranging from high school
code nerds to professional security consulting firms, hoping to make a name
for themselves by being the first to spot some vulnerability in Apache, the
Linux kernel, etc. That is an incredible free code inspection service. That
is the key to the security of open source (IMHO).

You can't say that for most in-house software. You all know what corporate
culture is like. #1 your boss is not paying you to scrutinize other
peoples' code. And #2 if you spot some flaw in Bob's code you keep your
head down, because Bob is such a grump and does not take criticism well.

And BTW this is coming from someone (me) who is basically a proprietary
software guy. I made my money writing conventionally-licensed proprietary
software. I have never contributed to an open source project.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of David Crayford
Sent: Friday, February 11, 2022 11:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Log4j hearing: 'Open source is not the problem'

On 12/2/22 4:56 am, Radoslaw Skorupka wrote:

Well, who said it is not a problem???

I do. I maintain that proprietary code has just as many vulnerabilities
as open source. In fact, I would suggest that open sour

Re: Fwd: Log4j hearing: 'Open source is not the problem'

2022-02-12 Thread Charles Mills
I don't disagree. That is the flip side of the situation.

I think what you wrote is true, and what I wrote is true.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Itschak Mugzach
Sent: Saturday, February 12, 2022 11:39 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Log4j hearing: 'Open source is not the problem'

If someone develops code that is vulnerable, only the organization he works
for is (potentially) affected and the attacker does not have access to the
code to play with. With open source, the code is accessible to everyone,
and the problem hits millions of organizations.

The problem is not the vendor that makes use of open source, it is the fact
that when the vulnerability is discovered, there is a time window until it
is patched. And this is only if it was discovered by an ethical bug hunter.

This is why I am not impressed (but do appreciate the effort) by the tools
David and his company uses. They do their best, but it will not help in
case of a zero date and the scale of an open source vulnerability is
unlimited compared to a specific local code, bad as it is.

The funny thing is that although millions of eyes look at "open source" (as
Chrles mentioned) they rarely find the vulnerability in a very
common, highly used code (such as log4jv2 that has been here since
2012...).

Saying that, open source is here to stay. Just don't wait for the vendor to
report on vulnerabilities. Scan it yourself frequently.

My two israeli shekels cents (Actually called "agorot").

ITschak

*| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere
Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux
and IBM I **|  *

*|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|*
*Skype**: ItschakMugzach **|* *Web**: www.Securiteam.co.il  **|*





On Sat, Feb 12, 2022 at 7:04 PM Charles Mills  wrote:

> Nobody asked me, but I think David buried the most important point in the
> middle. I have seen lots of TERRIBLE code written by "engineers from big
> tech." That's not the key point. The key point is
>
> > the code is in the open and can be scrutinized by millions of people
>
> There are thousands (if not millions) of people, ranging from high school
> code nerds to professional security consulting firms, hoping to make a name
> for themselves by being the first to spot some vulnerability in Apache, the
> Linux kernel, etc. That is an incredible free code inspection service. That
> is the key to the security of open source (IMHO).
>
> You can't say that for most in-house software. You all know what corporate
> culture is like. #1 your boss is not paying you to scrutinize other
> peoples' code. And #2 if you spot some flaw in Bob's code you keep your
> head down, because Bob is such a grump and does not take criticism well.
>
> And BTW this is coming from someone (me) who is basically a proprietary
> software guy. I made my money writing conventionally-licensed proprietary
> software. I have never contributed to an open source project.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of David Crayford
> Sent: Friday, February 11, 2022 11:39 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Fwd: Log4j hearing: 'Open source is not the problem'
>
> On 12/2/22 4:56 am, Radoslaw Skorupka wrote:
> > Well, who said it is not a problem???
>
> I do. I maintain that proprietary code has just as many vulnerabilities
> as open source. In fact, I would suggest that open source code is better
> as the standard of engineer tends to be much higher than your average
> Joe coder working for a bank. Also, the code is in the open and can be
> scrutinized by millions of people. Who do you think develops open source
> software? Is it hobbyists, enthusiasts, students, academics etc? The
> truth is it's mostly engineers from big tech who are getting paid to
> develop open source. Check out the authors of Apache Commons components
> and it's IBMers
> https://github.com/apache/commons-bsf/blob/master/AUTHORS.txt. IBM were
> the organization that stumped up the cash and resources to develop
> Eclipse. A huge amount of Apache open source code is written and
> maintained by IBM and it's used extensively in their products.
>
>
> > It sounds like "open source is free of bugs". However I have never
> > heard such claim.
>
> Nobody is saying that. That would be ignorant and stupid. All software
> has bugs.
>
>
> > More: companies use some kind of whitelisting open source software. In
> > many cases software developer is not allowed to use "fancy, shining
> > code" just because there some requirements

Re: Fwd: Log4j hearing: 'Open source is not the problem'

2022-02-12 Thread Itschak Mugzach
If someone develops code that is vulnerable, only the organization he works
for is (potentially) affected and the attacker does not have access to the
code to play with. With open source, the code is accessible to everyone,
and the problem hits millions of organizations.

The problem is not the vendor that makes use of open source, it is the fact
that when the vulnerability is discovered, there is a time window until it
is patched. And this is only if it was discovered by an ethical bug hunter.

This is why I am not impressed (but do appreciate the effort) by the tools
David and his company uses. They do their best, but it will not help in
case of a zero date and the scale of an open source vulnerability is
unlimited compared to a specific local code, bad as it is.

The funny thing is that although millions of eyes look at "open source" (as
Chrles mentioned) they rarely find the vulnerability in a very
common, highly used code (such as log4jv2 that has been here since
2012...).

Saying that, open source is here to stay. Just don't wait for the vendor to
report on vulnerabilities. Scan it yourself frequently.

My two israeli shekels cents (Actually called "agorot").

ITschak

*| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere
Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux
and IBM I **|  *

*|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|*
*Skype**: ItschakMugzach **|* *Web**: www.Securiteam.co.il  **|*





On Sat, Feb 12, 2022 at 7:04 PM Charles Mills  wrote:

> Nobody asked me, but I think David buried the most important point in the
> middle. I have seen lots of TERRIBLE code written by "engineers from big
> tech." That's not the key point. The key point is
>
> > the code is in the open and can be scrutinized by millions of people
>
> There are thousands (if not millions) of people, ranging from high school
> code nerds to professional security consulting firms, hoping to make a name
> for themselves by being the first to spot some vulnerability in Apache, the
> Linux kernel, etc. That is an incredible free code inspection service. That
> is the key to the security of open source (IMHO).
>
> You can't say that for most in-house software. You all know what corporate
> culture is like. #1 your boss is not paying you to scrutinize other
> peoples' code. And #2 if you spot some flaw in Bob's code you keep your
> head down, because Bob is such a grump and does not take criticism well.
>
> And BTW this is coming from someone (me) who is basically a proprietary
> software guy. I made my money writing conventionally-licensed proprietary
> software. I have never contributed to an open source project.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of David Crayford
> Sent: Friday, February 11, 2022 11:39 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Fwd: Log4j hearing: 'Open source is not the problem'
>
> On 12/2/22 4:56 am, Radoslaw Skorupka wrote:
> > Well, who said it is not a problem???
>
> I do. I maintain that proprietary code has just as many vulnerabilities
> as open source. In fact, I would suggest that open source code is better
> as the standard of engineer tends to be much higher than your average
> Joe coder working for a bank. Also, the code is in the open and can be
> scrutinized by millions of people. Who do you think develops open source
> software? Is it hobbyists, enthusiasts, students, academics etc? The
> truth is it's mostly engineers from big tech who are getting paid to
> develop open source. Check out the authors of Apache Commons components
> and it's IBMers
> https://github.com/apache/commons-bsf/blob/master/AUTHORS.txt. IBM were
> the organization that stumped up the cash and resources to develop
> Eclipse. A huge amount of Apache open source code is written and
> maintained by IBM and it's used extensively in their products.
>
>
> > It sounds like "open source is free of bugs". However I have never
> > heard such claim.
>
> Nobody is saying that. That would be ignorant and stupid. All software
> has bugs.
>
>
> > More: companies use some kind of whitelisting open source software. In
> > many cases software developer is not allowed to use "fancy, shining
> > code" just because there some requirements are on met. It can be
> > community, reputation, maturity, etc.
>
> How can a company whitelist open source software if they purchase a
> product from a vendor or IBM that uses open source? As our products are
> sold and marketed by IBM we provide them with a Certificate of
> Originality which is a bill of materials that lists all of the open
> source software (wit

Re: Fwd: Log4j hearing: 'Open source is not the problem'

2022-02-12 Thread Charles Mills
Nobody asked me, but I think David buried the most important point in the 
middle. I have seen lots of TERRIBLE code written by "engineers from big tech." 
That's not the key point. The key point is

> the code is in the open and can be scrutinized by millions of people

There are thousands (if not millions) of people, ranging from high school code 
nerds to professional security consulting firms, hoping to make a name for 
themselves by being the first to spot some vulnerability in Apache, the Linux 
kernel, etc. That is an incredible free code inspection service. That is the 
key to the security of open source (IMHO). 

You can't say that for most in-house software. You all know what corporate 
culture is like. #1 your boss is not paying you to scrutinize other peoples' 
code. And #2 if you spot some flaw in Bob's code you keep your head down, 
because Bob is such a grump and does not take criticism well.

And BTW this is coming from someone (me) who is basically a proprietary 
software guy. I made my money writing conventionally-licensed proprietary 
software. I have never contributed to an open source project.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of David Crayford
Sent: Friday, February 11, 2022 11:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Log4j hearing: 'Open source is not the problem'

On 12/2/22 4:56 am, Radoslaw Skorupka wrote:
> Well, who said it is not a problem???

I do. I maintain that proprietary code has just as many vulnerabilities 
as open source. In fact, I would suggest that open source code is better 
as the standard of engineer tends to be much higher than your average 
Joe coder working for a bank. Also, the code is in the open and can be 
scrutinized by millions of people. Who do you think develops open source 
software? Is it hobbyists, enthusiasts, students, academics etc? The 
truth is it's mostly engineers from big tech who are getting paid to 
develop open source. Check out the authors of Apache Commons components 
and it's IBMers 
https://github.com/apache/commons-bsf/blob/master/AUTHORS.txt. IBM were 
the organization that stumped up the cash and resources to develop 
Eclipse. A huge amount of Apache open source code is written and 
maintained by IBM and it's used extensively in their products.


> It sounds like "open source is free of bugs". However I have never 
> heard such claim.

Nobody is saying that. That would be ignorant and stupid. All software 
has bugs.


> More: companies use some kind of whitelisting open source software. In 
> many cases software developer is not allowed to use "fancy, shining 
> code" just because there some requirements are on met. It can be 
> community, reputation, maturity, etc.

How can a company whitelist open source software if they purchase a 
product from a vendor or IBM that uses open source? As our products are 
sold and marketed by IBM we provide them with a Certificate of 
Originality which is a bill of materials that lists all of the open 
source software (with versions) that we use. We scan all of our products 
as part of our DevOps pipeline. There are three types of scans:

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: Fwd: Log4j hearing: 'Open source is not the problem'

2022-02-11 Thread David Crayford

On 12/2/22 4:56 am, Radoslaw Skorupka wrote:

Well, who said it is not a problem???


I do. I maintain that proprietary code has just as many vulnerabilities 
as open source. In fact, I would suggest that open source code is better 
as the standard of engineer tends to be much higher than your average 
Joe coder working for a bank. Also, the code is in the open and can be 
scrutinized by millions of people. Who do you think develops open source 
software? Is it hobbyists, enthusiasts, students, academics etc? The 
truth is it's mostly engineers from big tech who are getting paid to 
develop open source. Check out the authors of Apache Commons components 
and it's IBMers 
https://github.com/apache/commons-bsf/blob/master/AUTHORS.txt. IBM were 
the organization that stumped up the cash and resources to develop 
Eclipse. A huge amount of Apache open source code is written and 
maintained by IBM and it's used extensively in their products.



It sounds like "open source is free of bugs". However I have never 
heard such claim.


Nobody is saying that. That would be ignorant and stupid. All software 
has bugs.



More: companies use some kind of whitelisting open source software. In 
many cases software developer is not allowed to use "fancy, shining 
code" just because there some requirements are on met. It can be 
community, reputation, maturity, etc.


How can a company whitelist open source software if they purchase a 
product from a vendor or IBM that uses open source? As our products are 
sold and marketed by IBM we provide them with a Certificate of 
Originality which is a bill of materials that lists all of the open 
source software (with versions) that we use. We scan all of our products 
as part of our DevOps pipeline. There are three types of scans:


SCA (Software Composition Analysis) detects open source libraries with 
known vulnerabilities. Also checks for license violations against 
policies such as forbidding GPL licensed software. It's interesting that 
nobody has posted about the JNDI vulnerability [1] found in the H2 
database which was similar to Log4Shell. As soon as the CVE was lodged 
our infosec team had scanned the Blackduck bill of materials data base 
and contacted all product owners that were using h2. A thread was also 
started in Slack so we could collaborate. SCA does not require source 
code. We use Blackduck.


SAST (Static Application Security Testing) scans source code and detects 
vulnerabilities in proprietary code, written in house. Shifts security 
left to detect vulnerabilities as early as possible. SAST scans provide 
a lot of false of false positives but it can find flaws. I regard it 
highly. We use Polaris.


DAST (Dynamic Application Security Testing) black box testing which can 
try to find vulnerabilities at runtime such as MITM attacks, SQL 
injection, DOM injection etc. We use Veracode.


Customers also scan our code using their tools. We took a case from a 
bank who had used Veracode to scan some of our HTTP client code and it 
discovered we were defaulting to TLSv1.1 for secure TCP connections. 
They wanted us to fix it to default to TLSV1.3, which we did.



[1] 
https://jfrog.com/blog/the-jndi-strikes-back-unauthenticated-rce-in-h2-database-console/




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: Fwd: Log4j hearing: 'Open source is not the problem'

2022-02-11 Thread Radoslaw Skorupka

Well, who said it is not a problem???
It sounds like "open source is free of bugs". However I have never heard 
such claim.
More: companies use some kind of whitelisting open source software. In 
many cases software developer is not allowed to use "fancy, shining 
code" just because there some requirements are on met. It can be 
community, reputation, maturity, etc.



--
Radoslaw Skorupka
Lodz, Poland



W dniu 09.02.2022 o 20:24, Mark Regan pisze:

https://www.networkworld.com/article/3649003/log4j-hearing-open-source-is-not-the-problem.html

marktre...@gmail.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Fwd: Log4j hearing: 'Open source is not the problem'

2022-02-09 Thread Mark Regan
https://www.networkworld.com/article/3649003/log4j-hearing-open-source-is-not-the-problem.html

marktre...@gmail.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN