[security-dev] char argument is weak
Anil.Saldhana at redhat.com
Fri Dec 7 11:08:55 EST 2012
Bill, good points. We should take a look at this issue seriously.
On 12/07/2012 09:15 AM, Bill Burke wrote:
> On 12/7/2012 9:20 AM, Darran Lofthouse wrote:
>> Reading this a lot of your justification appears to be that there are
>> other weak areas that also need to be addressed so lets address them
>> rather than using them as a justification.
>> Relying on a session token to identify a remote user is weak security,
>> no stronger than authenticating using plain text passwords.
> Most apps that run on Tomcat, Jetty, and JBossWeb use a session cookie.
> Also, How safe is SSL from this type of memory dump attack? Does it
> not have to keep the private key(s) in memory?
>> Having to have some passwords in memory may be an indication that some
>> of those also need to be reduced but don't see how it justifies keeping
>> more in memory.
> If you only fix one hole in a leaky roof, you still have a leaky roof.
> It is impossible to protect against this attack because you have no
> control when a swap happens let alone all the areas that must store
> credentials in memory over a long period.
> It is the responsibility of the OS to protect against this attack, not
> the JVM. This is very much like how people continually try to emulate
> SSL features with their own leaky protocols, when if they just used SSL
> to begin with they wouldn't have those leaks.
>> And regarding users that deserve their own fate we have been there, done
>> that and moved beyond that now - that really is the pre-Red Hat approach
>> we used to have.
> I disagree. This is one problem that can only *fully* be solved at the
> OS level. Since we are now post-Red Hat we actually have an OS as part
> of our portfolio, so we should delegate responsibility to RHEL where
> appropriate. This is one of those situations.
More information about the security-dev