What wallets are affected by the NPM package vulnerability?
Recently, a vulnerability was found in an open-source project used by some bitcoin wallet software (such as CoPay and BitPay).
Are there any other wallets known to be affected by this vulnerability?
If I am a user of this software, what steps can I take to secure my bitcoin?
copay bitpay weaknesses
asked Nov 27 '18 at 11:12
chytrik
6,2922624
add a comment |
Recently, a vulnerability was found in an open-source project used by some bitcoin wallet software (such as CoPay and BitPay).
Are there any other wallets known to be affected by this vulnerability?
If I am a user of this software, what steps can I take to secure my bitcoin?
copay bitpay weaknesses
asked Nov 27 '18 at 11:12
chytrik
6,2922624
add a comment |
Recently, a vulnerability was found in an open-source project used by some bitcoin wallet software (such as CoPay and BitPay).
Are there any other wallets known to be affected by this vulnerability?
If I am a user of this software, what steps can I take to secure my bitcoin?
copay bitpay weaknesses
asked Nov 27 '18 at 11:12
chytrik
6,2922624
Recently, a vulnerability was found in an open-source project used by some bitcoin wallet software (such as CoPay and BitPay).
Are there any other wallets known to be affected by this vulnerability?
If I am a user of this software, what steps can I take to secure my bitcoin?
copay bitpay weaknesses
copay bitpay weaknesses
asked Nov 27 '18 at 11:12
chytrik
6,2922624
asked Nov 27 '18 at 11:12
chytrik
6,2922624
asked Nov 27 '18 at 11:12
chytrik
6,2922624
asked Nov 27 '18 at 11:12
chytrik
6,2922624
asked Nov 27 '18 at 11:12
chytrik
6,2922624
6,2922624
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
Only Copay is affected by this vulnerability.
Although the package was included by many, many projects (both within and outside the crypto space), the attack payload was encrypted, and used the package description as a decryption key. They key in question was found to be (via brute force) A Secure Bitcoin Wallet, which is the npm description for the copay-dash package.
Thus, packages which did not have that as their description would be unable to decrypt, and hence execute, the payload.
Note that such attacks are feasible on any package that does not verify and pin its dependencies, even outside the nodejs ecosystem. Developers should work to ensure that they are importing vetted code, and pin (or even vendor) their dependencies. This is especially important for programs that deal with private keys.
answered Nov 27 '18 at 11:26
Raghav Sood
7,10811127
Can you define the verb "vendor"? I could only find the noun in major dictionaries.
– Kevin
Nov 27 '18 at 15:42
1
@Kevin Vendoring means to keep a copy of a specific version of an external code dependency within your repository, so that you are always sure of what code you are running. It also prevents a third party from changing code without changing the version number and slipping it into your application.
– Raghav Sood
Nov 27 '18 at 16:09
1
Ah. We do that all the time. It also makes it easier to fork the dependency and/or submit pull requests (which can be a double-edged sword if you don't have enough people or expertise to support a fork, but at least it gives you options).
– Kevin
Nov 27 '18 at 16:15
2
I think "self-hosting" is a clearer, more common term for what you call "vendoring" here, unless that's an established term in the JS community.
– Nic Hartley
Nov 27 '18 at 18:09
1
I picked vendoring based on what we call it in golang, I'm not 100% certain if the js folks have a specific term for it.
– Raghav Sood
Nov 27 '18 at 18:17
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "308"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fbitcoin.stackexchange.com%2fquestions%2f81407%2fwhat-wallets-are-affected-by-the-npm-package-vulnerability%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Only Copay is affected by this vulnerability.
Although the package was included by many, many projects (both within and outside the crypto space), the attack payload was encrypted, and used the package description as a decryption key. They key in question was found to be (via brute force) A Secure Bitcoin Wallet, which is the npm description for the copay-dash package.
Thus, packages which did not have that as their description would be unable to decrypt, and hence execute, the payload.
Note that such attacks are feasible on any package that does not verify and pin its dependencies, even outside the nodejs ecosystem. Developers should work to ensure that they are importing vetted code, and pin (or even vendor) their dependencies. This is especially important for programs that deal with private keys.
answered Nov 27 '18 at 11:26
Raghav Sood
7,10811127
Can you define the verb "vendor"? I could only find the noun in major dictionaries.
– Kevin
Nov 27 '18 at 15:42
1
@Kevin Vendoring means to keep a copy of a specific version of an external code dependency within your repository, so that you are always sure of what code you are running. It also prevents a third party from changing code without changing the version number and slipping it into your application.
– Raghav Sood
Nov 27 '18 at 16:09
1
Ah. We do that all the time. It also makes it easier to fork the dependency and/or submit pull requests (which can be a double-edged sword if you don't have enough people or expertise to support a fork, but at least it gives you options).
– Kevin
Nov 27 '18 at 16:15
2
I think "self-hosting" is a clearer, more common term for what you call "vendoring" here, unless that's an established term in the JS community.
– Nic Hartley
Nov 27 '18 at 18:09
1
I picked vendoring based on what we call it in golang, I'm not 100% certain if the js folks have a specific term for it.
– Raghav Sood
Nov 27 '18 at 18:17
add a comment |
Only Copay is affected by this vulnerability.
Although the package was included by many, many projects (both within and outside the crypto space), the attack payload was encrypted, and used the package description as a decryption key. They key in question was found to be (via brute force) A Secure Bitcoin Wallet, which is the npm description for the copay-dash package.
Thus, packages which did not have that as their description would be unable to decrypt, and hence execute, the payload.
Note that such attacks are feasible on any package that does not verify and pin its dependencies, even outside the nodejs ecosystem. Developers should work to ensure that they are importing vetted code, and pin (or even vendor) their dependencies. This is especially important for programs that deal with private keys.
answered Nov 27 '18 at 11:26
Raghav Sood
7,10811127
Can you define the verb "vendor"? I could only find the noun in major dictionaries.
– Kevin
Nov 27 '18 at 15:42
1
@Kevin Vendoring means to keep a copy of a specific version of an external code dependency within your repository, so that you are always sure of what code you are running. It also prevents a third party from changing code without changing the version number and slipping it into your application.
– Raghav Sood
Nov 27 '18 at 16:09
1
Ah. We do that all the time. It also makes it easier to fork the dependency and/or submit pull requests (which can be a double-edged sword if you don't have enough people or expertise to support a fork, but at least it gives you options).
– Kevin
Nov 27 '18 at 16:15
2
I think "self-hosting" is a clearer, more common term for what you call "vendoring" here, unless that's an established term in the JS community.
– Nic Hartley
Nov 27 '18 at 18:09
1
I picked vendoring based on what we call it in golang, I'm not 100% certain if the js folks have a specific term for it.
– Raghav Sood
Nov 27 '18 at 18:17
add a comment |
Only Copay is affected by this vulnerability.
Although the package was included by many, many projects (both within and outside the crypto space), the attack payload was encrypted, and used the package description as a decryption key. They key in question was found to be (via brute force) A Secure Bitcoin Wallet, which is the npm description for the copay-dash package.
Thus, packages which did not have that as their description would be unable to decrypt, and hence execute, the payload.
Note that such attacks are feasible on any package that does not verify and pin its dependencies, even outside the nodejs ecosystem. Developers should work to ensure that they are importing vetted code, and pin (or even vendor) their dependencies. This is especially important for programs that deal with private keys.
answered Nov 27 '18 at 11:26
Raghav Sood
7,10811127
Only Copay is affected by this vulnerability.
Although the package was included by many, many projects (both within and outside the crypto space), the attack payload was encrypted, and used the package description as a decryption key. They key in question was found to be (via brute force) A Secure Bitcoin Wallet, which is the npm description for the copay-dash package.
Thus, packages which did not have that as their description would be unable to decrypt, and hence execute, the payload.
Note that such attacks are feasible on any package that does not verify and pin its dependencies, even outside the nodejs ecosystem. Developers should work to ensure that they are importing vetted code, and pin (or even vendor) their dependencies. This is especially important for programs that deal with private keys.
answered Nov 27 '18 at 11:26
Raghav Sood
7,10811127
answered Nov 27 '18 at 11:26
Raghav Sood
7,10811127
answered Nov 27 '18 at 11:26
Raghav Sood
7,10811127
answered Nov 27 '18 at 11:26
Raghav Sood
7,10811127
7,10811127
Can you define the verb "vendor"? I could only find the noun in major dictionaries.
– Kevin
Nov 27 '18 at 15:42
1
@Kevin Vendoring means to keep a copy of a specific version of an external code dependency within your repository, so that you are always sure of what code you are running. It also prevents a third party from changing code without changing the version number and slipping it into your application.
– Raghav Sood
Nov 27 '18 at 16:09
1
Ah. We do that all the time. It also makes it easier to fork the dependency and/or submit pull requests (which can be a double-edged sword if you don't have enough people or expertise to support a fork, but at least it gives you options).
– Kevin
Nov 27 '18 at 16:15
2
I think "self-hosting" is a clearer, more common term for what you call "vendoring" here, unless that's an established term in the JS community.
– Nic Hartley
Nov 27 '18 at 18:09
1
I picked vendoring based on what we call it in golang, I'm not 100% certain if the js folks have a specific term for it.
– Raghav Sood
Nov 27 '18 at 18:17
add a comment |
Can you define the verb "vendor"? I could only find the noun in major dictionaries.
– Kevin
Nov 27 '18 at 15:42
1
@Kevin Vendoring means to keep a copy of a specific version of an external code dependency within your repository, so that you are always sure of what code you are running. It also prevents a third party from changing code without changing the version number and slipping it into your application.
– Raghav Sood
Nov 27 '18 at 16:09
1
Ah. We do that all the time. It also makes it easier to fork the dependency and/or submit pull requests (which can be a double-edged sword if you don't have enough people or expertise to support a fork, but at least it gives you options).
– Kevin
Nov 27 '18 at 16:15
2
I think "self-hosting" is a clearer, more common term for what you call "vendoring" here, unless that's an established term in the JS community.
– Nic Hartley
Nov 27 '18 at 18:09
1
I picked vendoring based on what we call it in golang, I'm not 100% certain if the js folks have a specific term for it.
– Raghav Sood
Nov 27 '18 at 18:17
Can you define the verb "vendor"? I could only find the noun in major dictionaries.
– Kevin
Nov 27 '18 at 15:42
Can you define the verb "vendor"? I could only find the noun in major dictionaries.
– Kevin
Nov 27 '18 at 15:42
1
1
@Kevin Vendoring means to keep a copy of a specific version of an external code dependency within your repository, so that you are always sure of what code you are running. It also prevents a third party from changing code without changing the version number and slipping it into your application.
– Raghav Sood
Nov 27 '18 at 16:09
@Kevin Vendoring means to keep a copy of a specific version of an external code dependency within your repository, so that you are always sure of what code you are running. It also prevents a third party from changing code without changing the version number and slipping it into your application.
– Raghav Sood
Nov 27 '18 at 16:09
1
1
Ah. We do that all the time. It also makes it easier to fork the dependency and/or submit pull requests (which can be a double-edged sword if you don't have enough people or expertise to support a fork, but at least it gives you options).
– Kevin
Nov 27 '18 at 16:15
Ah. We do that all the time. It also makes it easier to fork the dependency and/or submit pull requests (which can be a double-edged sword if you don't have enough people or expertise to support a fork, but at least it gives you options).
– Kevin
Nov 27 '18 at 16:15
2
2
I think "self-hosting" is a clearer, more common term for what you call "vendoring" here, unless that's an established term in the JS community.
– Nic Hartley
Nov 27 '18 at 18:09
I think "self-hosting" is a clearer, more common term for what you call "vendoring" here, unless that's an established term in the JS community.
– Nic Hartley
Nov 27 '18 at 18:09
1
1
I picked vendoring based on what we call it in golang, I'm not 100% certain if the js folks have a specific term for it.
– Raghav Sood
Nov 27 '18 at 18:17
I picked vendoring based on what we call it in golang, I'm not 100% certain if the js folks have a specific term for it.
– Raghav Sood
Nov 27 '18 at 18:17
add a comment |
Thanks for contributing an answer to Bitcoin Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fbitcoin.stackexchange.com%2fquestions%2f81407%2fwhat-wallets-are-affected-by-the-npm-package-vulnerability%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
