Re: PSA: critical security vulnerability in third-party pass-compatible software, "QtPass"

2018-01-04 Thread Niklas Hambüchen
On 04/01/2018 18.37, HacKan wrote:
> Well, any GUI could simply execute pass in the background... plain
> simple. QtPass is more than GUI, it is a whole implementation.

As I mentioned in the previous email, QtPass can be run in a mode where
it is not an implementation, but executes pass.
However, not yet for password generation.

I imagine for password generation, just shelling out to `pass generate`
won't do. Instead, something like `pass generate --no-save` will be
needed, that makes pass generate a password but not insert it into the
pass store.

This is so that the password can be inserted into QtPass's password
field in the GUI form, so that the user can pre-view it, and potentially
modify it according to whatever might be extra restrictions of the
system that needs to accept this password. For example, a common
workflow can be:

* User clicks "Generate" in the GUI's "New Password" form
* "Password" field in the form gets pre-filled by a password generated
by `pass`
* User copies the password to register to a web site
* Web site rejects the password, claiming that it must contain at least
one special character
* User appends a '!' to their generated password
* User copies the updated password to the website, which accepts it
* User clicks "Save" in the form in the GUI
* GUI calls `pass insert`
___
Password-Store mailing list
Password-Store@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/password-store


Re: PSA: critical security vulnerability in third-party pass-compatible software, "QtPass"

2018-01-04 Thread HacKan
Well, any GUI could simply execute pass in the background... plain
simple. QtPass is more than GUI, it is a whole implementation.


On 01/04/2018 02:33 PM, Niklas Hambüchen wrote:
> Hello Jason, thanks for this announcement, I think it's effective and
> useful to broadcast that here.
>
> On 04/01/2018 17.35, Jason A. Donenfeld wrote:
>> All passwords generated with "QtPass"'s built-in password generator
> Would it be possible to have QtPass or any other GUIs of this kind have
> `pass` generate the passwords for them? That way, it would always use
> whatever method `pass` thinks is best for generating passwords.
>
> It would be really great if GUIs like that could really just be GUIs and
> delegate all cryptographically relevant operations to `pass`.
>
> To my knowledge, QtPass, beyond being compatible with pass, already has
> an option in the settings to use the `pass` executable for all storage
> operations. But it doesn't have an option to make `pass` generate the
> passwords.
>
> Does `pass` already have an interface that QtPass could use to let it
> generate passwords?
>
> The only info I I've found on this so far is in
> https://github.com/IJHack/QtPass/issues/296#issuecomment-281176510,
> where the QtPass maintainer says:
>
> "
> I'm waiting for the upcoming release of pass which supports a plugin
> system and if I recall correctly a straight forward way to select a
> password generator too.
> "
>
> from February 2017.
> ___
> Password-Store mailing list
> Password-Store@lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/password-store

-- 
HacKan || Iván
GPG: 0x35710D312FDE468B

___
Password-Store mailing list
Password-Store@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/password-store


Re: PSA: critical security vulnerability in third-party pass-compatible software, "QtPass"

2018-01-04 Thread Niklas Hambüchen
Hello Jason, thanks for this announcement, I think it's effective and
useful to broadcast that here.

On 04/01/2018 17.35, Jason A. Donenfeld wrote:
> All passwords generated with "QtPass"'s built-in password generator

Would it be possible to have QtPass or any other GUIs of this kind have
`pass` generate the passwords for them? That way, it would always use
whatever method `pass` thinks is best for generating passwords.

It would be really great if GUIs like that could really just be GUIs and
delegate all cryptographically relevant operations to `pass`.

To my knowledge, QtPass, beyond being compatible with pass, already has
an option in the settings to use the `pass` executable for all storage
operations. But it doesn't have an option to make `pass` generate the
passwords.

Does `pass` already have an interface that QtPass could use to let it
generate passwords?

The only info I I've found on this so far is in
https://github.com/IJHack/QtPass/issues/296#issuecomment-281176510,
where the QtPass maintainer says:

"
I'm waiting for the upcoming release of pass which supports a plugin
system and if I recall correctly a straight forward way to select a
password generator too.
"

from February 2017.
___
Password-Store mailing list
Password-Store@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/password-store


PSA: critical security vulnerability in third-party pass-compatible software, "QtPass"

2018-01-04 Thread Jason A. Donenfeld
Hi folks,

"QtPass" is a separate project entirely from pass. It shares no code
with password store. However, the developer of "QtPass" hangs out on
this list, is part of the greater pass community, and "QtPass" is in
fact compatible and made to work with pass. Given the grave nature of
a recent software vulnerability in "QtPass", I feel like it might be
responsible to inform this list about it, in case there are any users
of this third party software here, despite it not actually being
related to the development of password store.

Bug report is here: https://github.com/IJHack/QtPass/issues/338
Fix landed in v1.2.1: https://github.com/IJHack/QtPass/releases/tag/v1.2.1

All passwords generated with "QtPass"'s built-in password generator
are possibly predictable and enumerable by hackers. The generator used
libc's random(), seeded with srand(msecs), where msecs is not the
msecs since 1970 (not that that'd be secure anyway), but rather the
msecs since the last second. This means there are only 1000 different
sequences of generated passwords.

If you're using this software, now would be a good time to change all
your passwords and regenerate them using a secure utility such as pass
(what this mailing list is about), or update to the latest version of
this third party "QtPass" software and regenerate from there. The fix
I proposed to the "QtPass" developers involves using Qt 5.10's
built-in CSPRNG wrapper, or /dev/urandom for older Qt versions.

Regards,
Jason
___
Password-Store mailing list
Password-Store@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/password-store


Re: Add support for *clip.exe* for Bash on Ubuntu on Windows

2018-01-04 Thread Kenny Evitt
Hi Jason,

Happy New Year!

I'd like to continue working on adding clipboard support for Bash on Ubuntu
on Windows (BUW).

I've got a working platform file that can both read from and write to the
clipboard. However, only text can be read and written. There's no way to
handle arbitrary data (e.g. an image file) on the clipboard on Windows. Is
that an issue?

I haven't thought of or run across any nice workarounds for the problem of
`uname` outputting "Linux" on BUW. Any thoughts?

Thanks,
Kenny

On Wed, Nov 22, 2017 at 1:10 PM, Kenny Evitt  wrote:

> Hi Jason,
>
> I finally had some time to work on this. I made some good progress
> initially – reading from and writing to the clipboard is easy and works
> (based on my very limited testing so far).
>
> However, I've run into the *effective* impossibility of being able to
> reading, and saving, arbitrary data from the Windows clipboard. Other
> software that does this actually *doesn't* do it – not in full generality.
> For example, AutoHotkey, a popular Windows scripting tool, seems to support
> specific formats and also *not *support other specific formats.
>
> Just based on this basic failure, I started wondering about the convention
> that Pass follows of even bothering to save the contents of the clipboard
> before writing data to it. What's the source of that convention? Why did
> you adopt it for Pass? Almost all other programs seem to just overwrite any
> existing data – why does Pass try to retain the original contents?
>
> I looked into the Cygwin */dev/clipboard* device and, probably more
> importantly, tested it myself with clipboard data that I wasn't (easily)
> able to save either – a JPG copied from the Google Chrome browser. Cygwin's
> clipboard doesn't contain any data for the image!
>
> So, given all of the above, is it sufficient that I can (easily) save and
> restore *text* in the Windows clipboard? Or do we want to aim for all data?
>
> Have you thought about how to handle the Ubuntu-on-Windows-reports-
> that-it-is-a-version-of-Linux-and-one-from-the-future-too problem? For
> now, for me just testing possible approaches, I'm working with a *linux.sh*
> platform file.
>
> Thanks,
> Kenny
>
> On Wed, Jul 26, 2017 at 10:41 AM, Jason A. Donenfeld 
> wrote:
>
>> Hi Kenny,
>>
>> Thanks for your response.
>>
>> > uname -r: 4.4.0-43-Microsoft
>> > uname -v: #1-Microsoft Wed Dec 31 14:42:53 PST 2014
>>
>> Microsoft has evidently built a time machine and made a 4.4.0 before
>> 4.4.0 existed! Surely if they can travel back in time, they can travel
>> into the future too. In that case, I will stop working on this, and
>> instead simply wait for them to bring pass compatibility back from a
>> future timeline in which I actually do do the work. Wait, paradox.
>>
>> > uname -r: 4.4.0-43-Microsoft
>>
>> So this is really unfortunate. It means the only way we have of
>> detecting WSL is by grepping uname -r. That seems like it won't mix
>> nicely with the current strategy of source "$(uname)...". I'm a bit
>> hesitant to bloat pass (even more) with non-standard Microsoft hacks,
>> especially since Windows isn't free software, but I'll see if I can
>> find a solution. If you have any suggestions, I'd be happy to hear
>> them.
>>
>> > There's a (mildly disgusting) way to shove everything into the platform
>> > file. PowerShell is installed by default on all versions of Windows
>> since
>> > Windows 7 and Windows Server 2008 R2 (both released at the end of 2009).
>> > Given that WSL is new for Windows 10, it sure seems like supporting WSL
>> > should imply we can safely expect PowerShell to be installed and
>> available.
>>
>> Great, sounds like a plan then,
>>
>> Regards,
>> Jason
>>
>
>
___
Password-Store mailing list
Password-Store@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/password-store