Error: Could not unbase64 the given bytes.

[roooneey]

After updating lastpass-cli to latest version (1.6.1) I suddenly get this error:

Error: Could not unbase64 the given bytes.

after adding new entries with

lpass add --non-interactive --sync=no

A combination of logout/relogin and sync seems to get rid of it, but shortly afterwards it will come back. I also tried all possible values for --sync parameter, however this doesn't change anything.

[kriation]

Based on my experience a few minutes ago in dealing with this same issue, I discovered that if I purged the contents of $XDG_DATA_HOME/lpass, logged back in using lpass login, I no longer observed this error.

[jwilliams-shadowsoft]

IMPORTANT: This is not a bug fix. There is still a bug here. I have invested this amount of time in order to determine a suitable workaround for me to use in my production playbooks, not suggesting that this is a suitable long-term solution.

I'm running tests against lpass using an Ansible playbook and encountering the same problems. Because the playbook can essentially stress test lpass it's pretty easy to overload it.

• Repeated "reads" (lpass show) do not seem to cause this.
• Repeated "creates" (lpass add) followed by "deletes" (lpass rm) sometimes result in this error. If a few "reads" are executed afterward, some will result in the "unbase64" error and some will behave normally.

Repeated tests varying 2 factors - sync interval and artificial delay between calls

Given two secrets A & B:

• Test run A
  • { Show A; Add A; Show B; Add B; Show A; Show B; Rm A; Rm B } x 2
  • { Show A; Add A; Show B; Add B; Show A; Show B; Rm A; Rm B } -- fails

If I place a 10-second delay between each lpass operation, everything seems to run better:

• Test run B
  • { Show A; Add A; Show B; Add B; Show A; Show B; Rm A; Rm B } x 5 -- success

I'm calling that a success. Because the timing of subsequent lpass executions seems to affect whether the "unbase64" error occurs, I'm going to say that this has something to do with caching, syncing, and the background lpass process.

Setting LPASS_AUTO_SYNC_TIME to 2 seconds and reducing my artificial delays to 4 seconds, logging out and back in:

• Test run C
  • { Show A; Add A; Show B; Add B; Show A; Show B; Rm A; Rm B } x 5 -- success

Since that worked so well, reducing LPASS_AUTO_SYNC_TIME to 1 seconds and reducing my artificial delays to 2 seconds, logging out and back in:

• Test run D
  • { Show A; Add A; Show B; Add B; Show A } -- fails on first iteration

This tells me that the timing is too close. Either the sync interval is freaking out the background process, or I'm not waiting long enough between my calls. Increasing my artificial delays to 3 seconds:

• Test run E
  • { Show A; Add A; Show B; Add B; Show A } -- fails on first iteration

Changing my artificial delay to 4 seconds:

• Test run F
  • { Show A; Add A; Show B; Add B; Show A; Show B; Rm A; Rm B } x 5 -- success

Based on this testing, it seems that stressing the sync / caching mechanism is a recipe for failure. Since test C used a sync time of 2 and a delay of 4 it seem right now that this is the most stable, since a sync time of 1 generally had trouble.

So what if we use a sync time of 2 and an artificial delay of 3:

• Test run G
  • { Show A; Add A; Show B; Add B; Show A; Show B; Rm A; Rm B } x 2
  • { Show A; Add A; Show B; Add B; Show A } -- fails

So sync time 2 and delay of 4 seems stable.

: X-axis: artificial delay
: Y-axis: sync time (LPASS_AUTO_SYNC_TYPE)

.	0	1	2	3	4	10
5 (default)	A: failed	.	.	.	.	B: success x 5
2	.	.	.	G: failure	C: success x 5	.
1	.	.	D: failed	E: failed	F: success	.

Repeated tests using factors close to tuning above

Because the goal is to have a reliable service that can always complete the requested operation,
I began testing the playbook in an infinite failure loop.
I loop on the playbook until it fails and report the number of iterations it took to fail.

• Sync interval: 2, artificial delay 4: failed within 5 iterations
• Sync interval: 2, artificial delay 5: failed within 4 iterations
• Sync interval: 2, artificial delay 8: still succeeding after 16 iterations

So apparently, as a workaround, we can just put artificial delays between operations and we will have relatively consistent success.

IMPORTANT: This is not a bug fix. There is still a bug here. I have invested this amount of time in order to determine a suitable workaround for me to use in my production playbooks, not suggesting that this is a suitable long-term solution.

NOTE: I have been able to clear the "unbase64" error by repeatedly using lpass rm to remove my 2 test secrets. I will get the error many times, then the rm starts working again.

[jwilliams-shadowsoft]

Please note: This is a bug.

[lamby]

I get this error when running the testsuite, as does Debian when it is building the package.

[ncopa]

This also affects Alpine Linux: #715 (comment)

[ncopa]

I believe this is related openssl-3.5. When building lastpass-cli-1.6.1 against openssl-3.3.3 the tests passes.

I believe there is something wrong in unbase64 that older versions of openssl was not so picky about: https://github.com/lastpass/lastpass-cli/blob/667da1f4b81371d203f433183b6d4fa4913d0b13/cipher.c#L304C1-L334C1

[ncopa]

it is the BIO_read that fails returns negative int:

lastpass-cli/cipher.c

Line 324 in 667da1f

goto error;

[ncopa]

I have run this in gdb and the input string to unbase64, cipher_unbase64 and cipher_aes_decrypt_base64 is "skipped". I believe that older openssl would not return error if the input was invalid base64.

This change makes the tests pass again:

diff --git a/blob.c b/blob.c
index e81493f..990e295 100644
--- a/blob.c
+++ b/blob.c
@@ -407,7 +407,7 @@ static struct account *account_parse(struct chunk *chunk, const unsigned char ke
        if (parsed->group[0] == 16)
                parsed->group[0] = '\0';
 
-       if (strlen(parsed->attachkey_encrypted)) {
+       if (strlen(parsed->attachkey_encrypted) && strcmp(parsed->attachkey_encrypted, "skipped") != 0) {
                parsed->attachkey = cipher_aes_decrypt_base64(
                        parsed->attachkey_encrypted, key);
        }

[lamby]

Thanks @ncopa - I can confirm that that works in Debian as well. I've added a versioned dependency on OpenSSL 3.5.

Cool pingu avi, too.

[ncopa]

I've added a versioned dependency on OpenSSL 3.5

You don't need that.

The problem was that lastpass-cli code depended on OpenSSL return success on invalid base64 input with empty output. Newer OpenSSL (3.5) is more strict on invalid input and will correctly return failure on invalid base64 input. The proposed fix is to special handle and avoid trying to decrypt it rather than rely on OpenSSL silently ignoring it.

[grugnog]

Thanks @ncopa - this fix worked for me - I added a PR above.

[rquadling]

I have JUST started using lpass (LastPass CLI v1.6.1.GIT), and got the Error: Could not unbase64 the given bytes. error between an lpass edit and an lpass show.

I "fixed" this with a sleep 1.

Clearly this is one of those things that isn't a fix, but it means I can move on with my work.

Maybe it will be of help to others!