You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Olivier Lamy <ol...@apache.org> on 2012/03/20 17:58:45 UTC
Security trouble
Hello Folks,
The default preemptive on for GET is probably a bad idea.
Imagine the following case, in your settings you have:
<server>
<username>olamy</username>
<password>reallycomplicatedpassword</password>
<id>foo.org</id>
</server>
During dependencies resolution, you get a pom with a repository.
<repository>
<id>foo.org</id>
<url>http://yourpasswordwillbehacked.org/</url>
</repository>
So with preemptive or not, you will expose your password to a server
you probably don't trust.
My idea are:
* preemptive off by default for GET
* adding a url element in server element in the settings. And when
using a remote repository send authz only if host:ip match
WDYT ?
Thanks,
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Security trouble
Posted by John Casey <jd...@commonjava.org>.
On 3/20/12 12:58 PM, Olivier Lamy wrote:
> Hello Folks,
>
> The default preemptive on for GET is probably a bad idea.
> Imagine the following case, in your settings you have:
>
> <server>
> <username>olamy</username>
> <password>reallycomplicatedpassword</password>
> <id>foo.org</id>
> </server>
>
> During dependencies resolution, you get a pom with a repository.
>
> <repository>
> <id>foo.org</id>
> <url>http://yourpasswordwillbehacked.org/</url>
> </repository>
>
> So with preemptive or not, you will expose your password to a server
> you probably don't trust.
>
> My idea are:
> * preemptive off by default for GET
> * adding a url element in server element in the settings. And when
> using a remote repository send authz only if host:ip match
>
> WDYT ?
+1000
Even if the server entry foo.org doesn't have a configuration for
preemptive authentication, http://yourpasswordwillbehacked.org/ could
still grab the password via BASIC authentication without much trouble.
In fact, it probably wouldn't be hard for someone to scan all the
repository entries in POMs on central, and write some sort of server to
serve POMs that have a ton of repository entries in it with all the
matching repo ids, just to harvest passwords.
They'd still have to socially engineer you into requesting the POM from
their server - or at least put a trigger POM out on central - but it's a
bit chilling nonetheless, IMO.
>
> Thanks,
--
John Casey
Developer, PMC Chair - Apache Maven (http://maven.apache.org)
Blog: http://www.johnofalltrades.name/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Security trouble
Posted by Brian Fox <br...@infinity.nu>.
On Tue, Mar 20, 2012 at 6:28 PM, Olivier Lamy <ol...@apache.org> wrote:
> 2012/3/20 Brian Fox <br...@infinity.nu>:
>> On Tue, Mar 20, 2012 at 5:07 PM, Olivier Lamy <ol...@apache.org> wrote:
>>> 2012/3/20 Brian Fox <br...@infinity.nu>:
>>>> On Tue, Mar 20, 2012 at 12:58 PM, Olivier Lamy <ol...@apache.org> wrote:
>>>>
>>>>> Hello Folks,
>>>>>
>>>>> The default preemptive on for GET is probably a bad idea.
>>>>> Imagine the following case, in your settings you have:
>>>>>
>>>>> <server>
>>>>> <username>olamy</username>
>>>>> <password>reallycomplicatedpassword</password>
>>>>> <id>foo.org</id>
>>>>> </server>
>>>>>
>>>>> During dependencies resolution, you get a pom with a repository.
>>>>>
>>>>> <repository>
>>>>> <id>foo.org</id>
>>>>> <url>http://yourpasswordwillbehacked.org/</url>
>>>>> </repository>
>>>>>
>>>>> So with preemptive or not, you will expose your password to a server
>>>>> you probably don't trust.
>>>>>
>>>>> My idea are:
>>>>> * preemptive off by default for GET
>>>>
>>>>
>>>> +1000
>>>>
>>>>>
>>>>> * adding a url element in server element in the settings. And when
>>>>> using a remote repository send authz only if host:ip match
>>>>>
>>>>
>>>> I'm concerned about compatibility with previous maven versions if we
>>>> do this as it's very common to share settings across different
>>>> versions (think m2 cli + m2e with embedded m3)
>>> Agree too. BTW at least at the beginning will be a [WARN]
>>>>
>>
>> Are you saying that all previous versions of maven just warn on new
>> elements in the settings.xml, or are you going to go back and
>> magically make them warn now? ;-)
> no :-)
>
> BTW do we consider adding a warning in 3.0.5 if id != host and fail in 3.0.6
> or fail directly in 3.0.5
I would start with a warning. It will take time to change poms and settings and
it's not a new concern (ie unrelated to pre-emptive auth). In fact,
this kind of change might make sense to call 3.1
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Security trouble
Posted by Olivier Lamy <ol...@apache.org>.
2012/3/27 Jason Dillon <ja...@planet57.com>:
> Why don't you just fix the parsers in older mavens (ie. make a new release of old-maven-version-x w/fixed parser) that allows for changes in newer versions?
>
> Seems like if you can never add new information to the pom to solve problems/add features in Maven 3 w/o completely breaking Maven 2, then Maven 3 really can not effectively grow and mature.
Agree. Furthermore the change will be in settings.xml not in pom.
>
>
> On Wednesday, March 21, 2012 at 6:57 AM, Brian Fox wrote:
>
>> On Wed, Mar 21, 2012 at 4:35 AM, Sascha Scholz <sascha.scholz@gmail.com (mailto:sascha.scholz@gmail.com)> wrote:
>> > Hi,
>> >
>> > On Tue, Mar 20, 2012 at 11:28 PM, Olivier Lamy <olamy@apache.org (mailto:olamy@apache.org)> wrote:
>> > > BTW do we consider adding a warning in 3.0.5 if id != host and fail in 3.0.6
>> > > or fail directly in 3.0.5
>> > >
>> >
>> >
>> > Why not deprecate the id entry then instead of forcing users to set
>> > both to the same value?
>> >
>>
>>
>> The xml parsing of older maven's isn't flexible enough to allow this.
>>
>> > BTW, I don't see that preemptive authentication makes things worse
>> > regarding security because an attacker could answer with a 401 to get
>> > the credentials even without preemptive authentication.
>> >
>>
>>
>> Correct.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org (mailto:dev-unsubscribe@maven.apache.org)
>> For additional commands, e-mail: dev-help@maven.apache.org (mailto:dev-help@maven.apache.org)
>>
>>
>
>
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Security trouble
Posted by Jason Dillon <ja...@planet57.com>.
Why don't you just fix the parsers in older mavens (ie. make a new release of old-maven-version-x w/fixed parser) that allows for changes in newer versions?
Seems like if you can never add new information to the pom to solve problems/add features in Maven 3 w/o completely breaking Maven 2, then Maven 3 really can not effectively grow and mature.
On Wednesday, March 21, 2012 at 6:57 AM, Brian Fox wrote:
> On Wed, Mar 21, 2012 at 4:35 AM, Sascha Scholz <sascha.scholz@gmail.com (mailto:sascha.scholz@gmail.com)> wrote:
> > Hi,
> >
> > On Tue, Mar 20, 2012 at 11:28 PM, Olivier Lamy <olamy@apache.org (mailto:olamy@apache.org)> wrote:
> > > BTW do we consider adding a warning in 3.0.5 if id != host and fail in 3.0.6
> > > or fail directly in 3.0.5
> > >
> >
> >
> > Why not deprecate the id entry then instead of forcing users to set
> > both to the same value?
> >
>
>
> The xml parsing of older maven's isn't flexible enough to allow this.
>
> > BTW, I don't see that preemptive authentication makes things worse
> > regarding security because an attacker could answer with a 401 to get
> > the credentials even without preemptive authentication.
> >
>
>
> Correct.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org (mailto:dev-unsubscribe@maven.apache.org)
> For additional commands, e-mail: dev-help@maven.apache.org (mailto:dev-help@maven.apache.org)
>
>
Re: Security trouble
Posted by Brian Fox <br...@infinity.nu>.
On Wed, Mar 21, 2012 at 4:35 AM, Sascha Scholz <sa...@gmail.com> wrote:
> Hi,
>
> On Tue, Mar 20, 2012 at 11:28 PM, Olivier Lamy <ol...@apache.org> wrote:
>> BTW do we consider adding a warning in 3.0.5 if id != host and fail in 3.0.6
>> or fail directly in 3.0.5
>
> Why not deprecate the id entry then instead of forcing users to set
> both to the same value?
>
The xml parsing of older maven's isn't flexible enough to allow this.
> BTW, I don't see that preemptive authentication makes things worse
> regarding security because an attacker could answer with a 401 to get
> the credentials even without preemptive authentication.
>
Correct.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Security trouble
Posted by Sascha Scholz <sa...@gmail.com>.
Hi,
On Tue, Mar 20, 2012 at 11:28 PM, Olivier Lamy <ol...@apache.org> wrote:
> BTW do we consider adding a warning in 3.0.5 if id != host and fail in 3.0.6
> or fail directly in 3.0.5
Why not deprecate the id entry then instead of forcing users to set
both to the same value?
BTW, I don't see that preemptive authentication makes things worse
regarding security because an attacker could answer with a 401 to get
the credentials even without preemptive authentication.
However, use of preemptive authentication introduced a regression for
us. Users had a server section in their settings.xml for our Nexus,
but we later changed Nexus to allow anonymous access. Without
preemptive authentication that worked because the unauthenticated
access was successful. With preemptive, users received a 403 because
the user/password combination wasn't valid any more.
Sascha
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Security trouble
Posted by Olivier Lamy <ol...@apache.org>.
2012/3/20 Brian Fox <br...@infinity.nu>:
> On Tue, Mar 20, 2012 at 5:07 PM, Olivier Lamy <ol...@apache.org> wrote:
>> 2012/3/20 Brian Fox <br...@infinity.nu>:
>>> On Tue, Mar 20, 2012 at 12:58 PM, Olivier Lamy <ol...@apache.org> wrote:
>>>
>>>> Hello Folks,
>>>>
>>>> The default preemptive on for GET is probably a bad idea.
>>>> Imagine the following case, in your settings you have:
>>>>
>>>> <server>
>>>> <username>olamy</username>
>>>> <password>reallycomplicatedpassword</password>
>>>> <id>foo.org</id>
>>>> </server>
>>>>
>>>> During dependencies resolution, you get a pom with a repository.
>>>>
>>>> <repository>
>>>> <id>foo.org</id>
>>>> <url>http://yourpasswordwillbehacked.org/</url>
>>>> </repository>
>>>>
>>>> So with preemptive or not, you will expose your password to a server
>>>> you probably don't trust.
>>>>
>>>> My idea are:
>>>> * preemptive off by default for GET
>>>
>>>
>>> +1000
>>>
>>>>
>>>> * adding a url element in server element in the settings. And when
>>>> using a remote repository send authz only if host:ip match
>>>>
>>>
>>> I'm concerned about compatibility with previous maven versions if we
>>> do this as it's very common to share settings across different
>>> versions (think m2 cli + m2e with embedded m3)
>> Agree too. BTW at least at the beginning will be a [WARN]
>>>
>
> Are you saying that all previous versions of maven just warn on new
> elements in the settings.xml, or are you going to go back and
> magically make them warn now? ;-)
no :-)
BTW do we consider adding a warning in 3.0.5 if id != host and fail in 3.0.6
or fail directly in 3.0.5
>
>> why not even if not self documented by xml element names :-)
>>
>
> See above.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Security trouble
Posted by Brian Fox <br...@infinity.nu>.
On Tue, Mar 20, 2012 at 5:07 PM, Olivier Lamy <ol...@apache.org> wrote:
> 2012/3/20 Brian Fox <br...@infinity.nu>:
>> On Tue, Mar 20, 2012 at 12:58 PM, Olivier Lamy <ol...@apache.org> wrote:
>>
>>> Hello Folks,
>>>
>>> The default preemptive on for GET is probably a bad idea.
>>> Imagine the following case, in your settings you have:
>>>
>>> <server>
>>> <username>olamy</username>
>>> <password>reallycomplicatedpassword</password>
>>> <id>foo.org</id>
>>> </server>
>>>
>>> During dependencies resolution, you get a pom with a repository.
>>>
>>> <repository>
>>> <id>foo.org</id>
>>> <url>http://yourpasswordwillbehacked.org/</url>
>>> </repository>
>>>
>>> So with preemptive or not, you will expose your password to a server
>>> you probably don't trust.
>>>
>>> My idea are:
>>> * preemptive off by default for GET
>>
>>
>> +1000
>>
>>>
>>> * adding a url element in server element in the settings. And when
>>> using a remote repository send authz only if host:ip match
>>>
>>
>> I'm concerned about compatibility with previous maven versions if we
>> do this as it's very common to share settings across different
>> versions (think m2 cli + m2e with embedded m3)
> Agree too. BTW at least at the beginning will be a [WARN]
>>
Are you saying that all previous versions of maven just warn on new
elements in the settings.xml, or are you going to go back and
magically make them warn now? ;-)
> why not even if not self documented by xml element names :-)
>
See above.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Security trouble
Posted by Olivier Lamy <ol...@apache.org>.
2012/3/20 Brian Fox <br...@infinity.nu>:
> On Tue, Mar 20, 2012 at 12:58 PM, Olivier Lamy <ol...@apache.org> wrote:
>
>> Hello Folks,
>>
>> The default preemptive on for GET is probably a bad idea.
>> Imagine the following case, in your settings you have:
>>
>> <server>
>> <username>olamy</username>
>> <password>reallycomplicatedpassword</password>
>> <id>foo.org</id>
>> </server>
>>
>> During dependencies resolution, you get a pom with a repository.
>>
>> <repository>
>> <id>foo.org</id>
>> <url>http://yourpasswordwillbehacked.org/</url>
>> </repository>
>>
>> So with preemptive or not, you will expose your password to a server
>> you probably don't trust.
>>
>> My idea are:
>> * preemptive off by default for GET
>
>
> +1000
>
>>
>> * adding a url element in server element in the settings. And when
>> using a remote repository send authz only if host:ip match
>>
>
> I'm concerned about compatibility with previous maven versions if we
> do this as it's very common to share settings across different
> versions (think m2 cli + m2e with embedded m3)
Agree too. BTW at least at the beginning will be a [WARN]
>
> But there is an issue here that needs to be solved. Perhaps instead of
> a new element, we introduce a way such that the id can be a dns entry
> and then we only use the credentials if the dns and id match.
>
>
> ie
>
> <repository>
> <id>foo.org</id>
> <url>http://yourpasswordwillbehacked.org/</url>
> </repository>
>
> won't send any credentials, even if asked via a 401 response whereas
>
> <repository>
> <id>foo.org</id>
> <url>http://therealthing.foo.org/repo1</url>
> </repository>
why not even if not self documented by xml element names :-)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Security trouble
Posted by Brian Fox <br...@infinity.nu>.
On Tue, Mar 20, 2012 at 12:58 PM, Olivier Lamy <ol...@apache.org> wrote:
> Hello Folks,
>
> The default preemptive on for GET is probably a bad idea.
> Imagine the following case, in your settings you have:
>
> <server>
> <username>olamy</username>
> <password>reallycomplicatedpassword</password>
> <id>foo.org</id>
> </server>
>
> During dependencies resolution, you get a pom with a repository.
>
> <repository>
> <id>foo.org</id>
> <url>http://yourpasswordwillbehacked.org/</url>
> </repository>
>
> So with preemptive or not, you will expose your password to a server
> you probably don't trust.
>
> My idea are:
> * preemptive off by default for GET
+1000
>
> * adding a url element in server element in the settings. And when
> using a remote repository send authz only if host:ip match
>
I'm concerned about compatibility with previous maven versions if we
do this as it's very common to share settings across different
versions (think m2 cli + m2e with embedded m3)
But there is an issue here that needs to be solved. Perhaps instead of
a new element, we introduce a way such that the id can be a dns entry
and then we only use the credentials if the dns and id match.
ie
<repository>
<id>foo.org</id>
<url>http://yourpasswordwillbehacked.org/</url>
</repository>
won't send any credentials, even if asked via a 401 response whereas
<repository>
<id>foo.org</id>
<url>http://therealthing.foo.org/repo1</url>
</repository>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org