Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

man-in-the-middle attack report (maybe) #1562

Closed
intuxicated opened this Issue · 4 comments

3 participants

@intuxicated

hi
i got this today :

dani@localhost /srv/http/sf % php composer.phar create-project symfony/framework-standard-edition path/ 2.1.7
The contents of https://packagist.org/p/providers-active.json do not match its signature, this is most likely due to a temporary glitch but could indicate a man-in-the-middle attack. Try running composer again and please report it if it still persists.
@blainesch

What IP do you get when you ping packagist?

@intuxicated

i try to install symfony via composer and i don't see that alert anymore.
ip:

PING packagist.org (37.59.4.156) 56(84) bytes of data.
@coudenysj

I do have this notice from time to time, but "this is most likely due to a temporary glitch", because a few seconds later I have a normal connection.

Could you try again?

@intuxicated

no more error.

@intuxicated intuxicated closed this
@edas edas referenced this issue from a commit
@edas edas Throw Exception on broken signature
This is related to issue #1562

With a fresh installation of Composer I had the following message:

> The contents of https://packagist.org/p/providers-latest.json do not
match its signature, this is most likely due to a temporary glitch but
could indicate a man-in-the-middle attack.
> Try running composer again and please report it if it still persists.

This was *probably* a temporary glitch, as the error did not appear
again, even after a full reinstallation of all packages.

*However* Composer had no way to differentiate a man-in-the-middle
attack and a temporary glitch. The installation / update did continue
despite the problem and files where installed / updates with no easy
rollback. These files may have been corrupted with malicious code and I
have no way to check they don't.

This is a *serious* security issue.

The code in [ComposerRepository line
434](https://github.com/composer/composer/blob/master/src/Composer/Repos
itory/ComposerRepository.php#L434) states

```php
// TODO throw SecurityException and abort once we are sure this can not
happen accidentally
````

Even if the broken signature may happen in accidentally in a standard
process, if it may be a security issue, we have to abort the procedure,
or at least ask for confirmation to the user. If it helps continuing
despite the temporary glitch, it may be possible to add a command line
switch like `--ignore-signature` to force the process to continue.

Proposed :
Send a RepositorySecurityException instead of the warning, even if this
may happen accidentally
59f8be3
@digitalkaoz digitalkaoz referenced this issue from a commit in digitalkaoz/composer
@edas edas Throw Exception on broken signature
This is related to issue #1562

With a fresh installation of Composer I had the following message:

> The contents of https://packagist.org/p/providers-latest.json do not
match its signature, this is most likely due to a temporary glitch but
could indicate a man-in-the-middle attack.
> Try running composer again and please report it if it still persists.

This was *probably* a temporary glitch, as the error did not appear
again, even after a full reinstallation of all packages.

*However* Composer had no way to differentiate a man-in-the-middle
attack and a temporary glitch. The installation / update did continue
despite the problem and files where installed / updates with no easy
rollback. These files may have been corrupted with malicious code and I
have no way to check they don't.

This is a *serious* security issue.

The code in [ComposerRepository line
434](https://github.com/composer/composer/blob/master/src/Composer/Repos
itory/ComposerRepository.php#L434) states

```php
// TODO throw SecurityException and abort once we are sure this can not
happen accidentally
````

Even if the broken signature may happen in accidentally in a standard
process, if it may be a security issue, we have to abort the procedure,
or at least ask for confirmation to the user. If it helps continuing
despite the temporary glitch, it may be possible to add a command line
switch like `--ignore-signature` to force the process to continue.

Proposed :
Send a RepositorySecurityException instead of the warning, even if this
may happen accidentally
3ff6d00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.