Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
I read the 1Password advisory on the WebP issue. Two things that were important to realize:

an attacker needs to share an account with a victim to perform the attack.

and

By default, 1Password apps don’t permit creating WebP images. However, if an attacker uses a maliciously modified client, they may be able to create WebP images regardless.

So, if one of my family members uses a modified 1Password program, they could compromise me if I display something from their account. This could happen if they downloaded 1Password from unofficial site.
 
I believe electron apps are impacted and if that is true, then its possible that would include bitwarden

Looks like 1PW has addressed the issue as noted here (dated as of 09/14/23): https://support.1password.com/kb/202309/

That link is the document that I was quoting. 1Password pushed out the patch within two days from the vulnerabilities report.

If Bitwarden is affected and has yet to patch it, then they are very, very slow. I hope they're not affected for the sake of their reputation.
 
That link is the document that I was quoting. 1Password pushed out the patch within two days from the vulnerabilities report.

If Bitwarden is affected and has yet to patch it, then they are very, very slow. I hope they're not affected for the sake of their reputation.

From what I'm reading now, any Electron application that uses the libwebp library is vulnerable. So here is the key issue.. since BitWarden is FOSS, the source should be available to see if they use the libwebp library. If you have a binary of it that isn't stripped, you should be able to run 'ldd /path/to/bitwarden binary' to see which libraries it uses (at least in a Linux environment). If you see libwebp, you're vulnerable.

BL.
 
From what I'm reading now, any Electron application that uses the libwebp library is vulnerable. So here is the key issue.. since BitWarden is FOSS, the source should be available to see if they use the libwebp library. If you have a binary of it that isn't stripped, you should be able to run 'ldd /path/to/bitwarden binary' to see which libraries it uses (at least in a Linux environment). If you see libwebp, you're vulnerable.

BL.
I don't think Bitwarden actually stores images of any kind that I can find, so that might be why they haven't issued an update.
 
From what I'm reading now, any Electron application that uses the libwebp library is vulnerable. So here is the key issue.. since BitWarden is FOSS, the source should be available to see if they use the libwebp library. If you have a binary of it that isn't stripped, you should be able to run 'ldd /path/to/bitwarden binary' to see which libraries it uses (at least in a Linux environment). If you see libwebp, you're vulnerable.

BL.
libwebp was patched. You'd have to check the version that you're running.
 
libwebp was patched. You'd have to check the version that you're running.

True, but it may also depend on if the binary was dynamically or statically linked. If dynamically linked, then the binary should be safe. If it was statically linked, then the vulnerability could still exist in the binary if it was compiled before libwebp was updated.

BL.
 
True, but it may also depend on if the binary was dynamically or statically linked. If dynamically linked, then the binary should be safe. If it was statically linked, then the vulnerability could still exist in the binary if it was compiled before libwebp was updated.

BL.

There's also the chance that the software doesn't use the library even if it's present.
 
There's also the chance that the software doesn't use the library even if it's present.

True.. which is why the ldd test would be necessary; you're testing if the binary links to the library. If it doesn't, you're good; if it does, then you may be vulnerable.

BL.
 
True.. which is why the ldd test would be necessary; you're testing if the binary links to the library. If it doesn't, you're good; if it does, then you may be vulnerable.

BL.
Good grief!

I remember the good ole days when the only concern was whether someone was specifying enough KDF iterations.
 
I read the 1Password advisory on the WebP issue. Two things that were important to realize:



and



So, if one of my family members uses a modified 1Password program, they could compromise me if I display something from their account. This could happen if they downloaded 1Password from unofficial site.

I can imagine all the corporate implementation of password managers and other software. i hear corporates do not like to update their software.

Let me correct that. If you purchased software then you should have a backup copy of the software so you can reinstall it.

thats an acceptable opinion since once the exchange happens seller is not longer responsible to keep providing it for you, although would be reputable of the vendor.

That being said, now with App Stores, in many cases you are not allowed the install files.
 
I have purchased software in the past where the seller offered, for a price, the ability to redownload the software at a later date. I always found it obnoxious, but that does set precedent that suggests a vendor is not responsible to provide software well after the purchase. I don't mean this to defend 1Password's behavior.

One thing that could be motivating them is that they might not be spending much time to keep up with the security of earlier versions. They might be exposing themselves to legal risk if the software is not up to the task and they provide it to customers.
 
  • Like
Reactions: DCIFRTHS
I have purchased software in the past where the seller offered, for a price, the ability to redownload the software at a later date. I always found it obnoxious, but that does set precedent that suggests a vendor is not responsible to provide software well after the purchase. I don't mean this to defend 1Password's behavior.

One thing that could be motivating them is that they might not be spending much time to keep up with the security of earlier versions. They might be exposing themselves to legal risk if the software is not up to the task and they provide it to customers.

why would they be at risk if they say its unsupported and no longer sell it, they just give download link to those who previously bought it which would only open with a license key
 
I have purchased software in the past where the seller offered, for a price, the ability to redownload the software at a later date. I always found it obnoxious,
Yup, Snagit does this. I just have the install saved if I need to re-install the app.
 
  • Like
Reactions: max2
why would they be at risk if they say its unsupported and no longer sell it, they just give download link to those who previously bought it which would only open with a license key
I'm not a lawyer. I would have to discuss the risks with a lawyer if I were running a password company and planned to offer a download that might have known vulnerabilities. I live in the US; I believe the risks of a lawsuit if someone suffered harm from the software would be high. But, I really don't know.
 
From what I'm reading now, any Electron application that uses the libwebp library is vulnerable. So here is the key issue.. since BitWarden is FOSS, the source should be available to see if they use the libwebp library. If you have a binary of it that isn't stripped, you should be able to run 'ldd /path/to/bitwarden binary' to see which libraries it uses (at least in a Linux environment). If you see libwebp, you're vulnerable.

BL.

About open source being the key issue - I ran ldd against 1Password and got a long list of libraries. libwebp is not there. 1Password isn't open source software, but ldd still worked. Am I only seeing a partial list because it's not open source? Here's what I see:

linux-vdso.so.1 (0x0000ffff94817000)
libffmpeg.so => /opt/1Password/./libffmpeg.so (0x0000ffff8abd0000)
libdl.so.2 => /lib/aarch64-linux-gnu/libdl.so.2 (0x0000ffff8aba0000)
libpthread.so.0 => /lib/aarch64-linux-gnu/libpthread.so.0 (0x0000ffff8ab80000)
libgobject-2.0.so.0 => /lib/aarch64-linux-gnu/libgobject-2.0.so.0 (0x0000ffff8ab00000)
libglib-2.0.so.0 => /lib/aarch64-linux-gnu/libglib-2.0.so.0 (0x0000ffff8a9b0000)
libgio-2.0.so.0 => /lib/aarch64-linux-gnu/libgio-2.0.so.0 (0x0000ffff8a7b0000)
libnss3.so => /lib/aarch64-linux-gnu/libnss3.so (0x0000ffff8a690000)
libnssutil3.so => /lib/aarch64-linux-gnu/libnssutil3.so (0x0000ffff8a640000)
libsmime3.so => /lib/aarch64-linux-gnu/libsmime3.so (0x0000ffff8a600000)
libnspr4.so => /lib/aarch64-linux-gnu/libnspr4.so (0x0000ffff8a5b0000)
libatk-1.0.so.0 => /lib/aarch64-linux-gnu/libatk-1.0.so.0 (0x0000ffff8a570000)
libatk-bridge-2.0.so.0 => /lib/aarch64-linux-gnu/libatk-bridge-2.0.so.0 (0x0000ffff8a520000)
libcups.so.2 => /lib/aarch64-linux-gnu/libcups.so.2 (0x0000ffff8a470000)
libdbus-1.so.3 => /lib/aarch64-linux-gnu/libdbus-1.so.3 (0x0000ffff8a410000)
libgtk-3.so.0 => /lib/aarch64-linux-gnu/libgtk-3.so.0 (0x0000ffff89bb0000)
libpango-1.0.so.0 => /lib/aarch64-linux-gnu/libpango-1.0.so.0 (0x0000ffff89b30000)
libcairo.so.2 => /lib/aarch64-linux-gnu/libcairo.so.2 (0x0000ffff89a00000)
libX11.so.6 => /lib/aarch64-linux-gnu/libX11.so.6 (0x0000ffff898b0000)
libXcomposite.so.1 => /lib/aarch64-linux-gnu/libXcomposite.so.1 (0x0000ffff89890000)
libXdamage.so.1 => /lib/aarch64-linux-gnu/libXdamage.so.1 (0x0000ffff89870000)
libXext.so.6 => /lib/aarch64-linux-gnu/libXext.so.6 (0x0000ffff89840000)
libXfixes.so.3 => /lib/aarch64-linux-gnu/libXfixes.so.3 (0x0000ffff89820000)
libXrandr.so.2 => /lib/aarch64-linux-gnu/libXrandr.so.2 (0x0000ffff89800000)
libgbm.so.1 => /lib/aarch64-linux-gnu/libgbm.so.1 (0x0000ffff897e0000)
libdrm.so.2 => /lib/aarch64-linux-gnu/libdrm.so.2 (0x0000ffff897b0000)
libexpat.so.1 => /lib/aarch64-linux-gnu/libexpat.so.1 (0x0000ffff89770000)
libxcb.so.1 => /lib/aarch64-linux-gnu/libxcb.so.1 (0x0000ffff89730000)
libxkbcommon.so.0 => /lib/aarch64-linux-gnu/libxkbcommon.so.0 (0x0000ffff896d0000)
libasound.so.2 => /lib/aarch64-linux-gnu/libasound.so.2 (0x0000ffff895b0000)
libatspi.so.0 => /lib/aarch64-linux-gnu/libatspi.so.0 (0x0000ffff89560000)
libm.so.6 => /lib/aarch64-linux-gnu/libm.so.6 (0x0000ffff894c0000)
libgcc_s.so.1 => /lib/aarch64-linux-gnu/libgcc_s.so.1 (0x0000ffff89490000)
libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000ffff892e0000)
/lib/ld-linux-aarch64.so.1 (0x0000ffff947de000)
libffi.so.8 => /lib/aarch64-linux-gnu/libffi.so.8 (0x0000ffff892c0000)
libpcre.so.3 => /lib/aarch64-linux-gnu/libpcre.so.3 (0x0000ffff89240000)
libgmodule-2.0.so.0 => /lib/aarch64-linux-gnu/libgmodule-2.0.so.0 (0x0000ffff89220000)
libz.so.1 => /lib/aarch64-linux-gnu/libz.so.1 (0x0000ffff891f0000)
libmount.so.1 => /lib/aarch64-linux-gnu/libmount.so.1 (0x0000ffff89190000)
libselinux.so.1 => /lib/aarch64-linux-gnu/libselinux.so.1 (0x0000ffff89150000)
libplc4.so => /lib/aarch64-linux-gnu/libplc4.so (0x0000ffff89130000)
libplds4.so => /lib/aarch64-linux-gnu/libplds4.so (0x0000ffff89110000)
libgssapi_krb5.so.2 => /lib/aarch64-linux-gnu/libgssapi_krb5.so.2 (0x0000ffff890b0000)
libavahi-common.so.3 => /lib/aarch64-linux-gnu/libavahi-common.so.3 (0x0000ffff89090000)
libavahi-client.so.3 => /lib/aarch64-linux-gnu/libavahi-client.so.3 (0x0000ffff89060000)
libgnutls.so.30 => /lib/aarch64-linux-gnu/libgnutls.so.30 (0x0000ffff88e60000)
libsystemd.so.0 => /lib/aarch64-linux-gnu/libsystemd.so.0 (0x0000ffff88d80000)
libgdk-3.so.0 => /lib/aarch64-linux-gnu/libgdk-3.so.0 (0x0000ffff88c60000)
libpangocairo-1.0.so.0 => /lib/aarch64-linux-gnu/libpangocairo-1.0.so.0 (0x0000ffff88c40000)
libXi.so.6 => /lib/aarch64-linux-gnu/libXi.so.6 (0x0000ffff88c10000)
libcairo-gobject.so.2 => /lib/aarch64-linux-gnu/libcairo-gobject.so.2 (0x0000ffff88bf0000)
libgdk_pixbuf-2.0.so.0 => /lib/aarch64-linux-gnu/libgdk_pixbuf-2.0.so.0 (0x0000ffff88bb0000)
libepoxy.so.0 => /lib/aarch64-linux-gnu/libepoxy.so.0 (0x0000ffff88a50000)
libfribidi.so.0 => /lib/aarch64-linux-gnu/libfribidi.so.0 (0x0000ffff88a20000)
libpangoft2-1.0.so.0 => /lib/aarch64-linux-gnu/libpangoft2-1.0.so.0 (0x0000ffff889f0000)
libharfbuzz.so.0 => /lib/aarch64-linux-gnu/libharfbuzz.so.0 (0x0000ffff88910000)
libfontconfig.so.1 => /lib/aarch64-linux-gnu/libfontconfig.so.1 (0x0000ffff888b0000)
libthai.so.0 => /lib/aarch64-linux-gnu/libthai.so.0 (0x0000ffff88890000)
libpixman-1.so.0 => /lib/aarch64-linux-gnu/libpixman-1.so.0 (0x0000ffff88810000)
libfreetype.so.6 => /lib/aarch64-linux-gnu/libfreetype.so.6 (0x0000ffff88740000)
libpng16.so.16 => /lib/aarch64-linux-gnu/libpng16.so.16 (0x0000ffff886f0000)
libxcb-shm.so.0 => /lib/aarch64-linux-gnu/libxcb-shm.so.0 (0x0000ffff886d0000)
libxcb-render.so.0 => /lib/aarch64-linux-gnu/libxcb-render.so.0 (0x0000ffff886b0000)
libXrender.so.1 => /lib/aarch64-linux-gnu/libXrender.so.1 (0x0000ffff88690000)
libwayland-server.so.0 => /lib/aarch64-linux-gnu/libwayland-server.so.0 (0x0000ffff88660000)
libXau.so.6 => /lib/aarch64-linux-gnu/libXau.so.6 (0x0000ffff88640000)
libXdmcp.so.6 => /lib/aarch64-linux-gnu/libXdmcp.so.6 (0x0000ffff88620000)
libblkid.so.1 => /lib/aarch64-linux-gnu/libblkid.so.1 (0x0000ffff885d0000)
libpcre2-8.so.0 => /lib/aarch64-linux-gnu/libpcre2-8.so.0 (0x0000ffff88530000)
libkrb5.so.3 => /lib/aarch64-linux-gnu/libkrb5.so.3 (0x0000ffff88450000)
libk5crypto.so.3 => /lib/aarch64-linux-gnu/libk5crypto.so.3 (0x0000ffff88410000)
libcom_err.so.2 => /lib/aarch64-linux-gnu/libcom_err.so.2 (0x0000ffff883f0000)
libkrb5support.so.0 => /lib/aarch64-linux-gnu/libkrb5support.so.0 (0x0000ffff883d0000)
libp11-kit.so.0 => /lib/aarch64-linux-gnu/libp11-kit.so.0 (0x0000ffff88280000)
libidn2.so.0 => /lib/aarch64-linux-gnu/libidn2.so.0 (0x0000ffff88250000)
libunistring.so.2 => /lib/aarch64-linux-gnu/libunistring.so.2 (0x0000ffff88090000)
libtasn1.so.6 => /lib/aarch64-linux-gnu/libtasn1.so.6 (0x0000ffff88060000)
libnettle.so.8 => /lib/aarch64-linux-gnu/libnettle.so.8 (0x0000ffff88000000)
libhogweed.so.6 => /lib/aarch64-linux-gnu/libhogweed.so.6 (0x0000ffff87fa0000)
libgmp.so.10 => /lib/aarch64-linux-gnu/libgmp.so.10 (0x0000ffff87f10000)
liblzma.so.5 => /lib/aarch64-linux-gnu/liblzma.so.5 (0x0000ffff87ed0000)
libzstd.so.1 => /lib/aarch64-linux-gnu/libzstd.so.1 (0x0000ffff87e00000)
liblz4.so.1 => /lib/aarch64-linux-gnu/liblz4.so.1 (0x0000ffff87dd0000)
libcap.so.2 => /lib/aarch64-linux-gnu/libcap.so.2 (0x0000ffff87db0000)
libgcrypt.so.20 => /lib/aarch64-linux-gnu/libgcrypt.so.20 (0x0000ffff87cc0000)
libXinerama.so.1 => /lib/aarch64-linux-gnu/libXinerama.so.1 (0x0000ffff87ca0000)
libXcursor.so.1 => /lib/aarch64-linux-gnu/libXcursor.so.1 (0x0000ffff87c80000)
libwayland-cursor.so.0 => /lib/aarch64-linux-gnu/libwayland-cursor.so.0 (0x0000ffff87c60000)
libwayland-egl.so.1 => /lib/aarch64-linux-gnu/libwayland-egl.so.1 (0x0000ffff87c40000)
libwayland-client.so.0 => /lib/aarch64-linux-gnu/libwayland-client.so.0 (0x0000ffff87c20000)
libjpeg.so.8 => /lib/aarch64-linux-gnu/libjpeg.so.8 (0x0000ffff87bc0000)
libgraphite2.so.3 => /lib/aarch64-linux-gnu/libgraphite2.so.3 (0x0000ffff87b90000)
libuuid.so.1 => /lib/aarch64-linux-gnu/libuuid.so.1 (0x0000ffff87b70000)
libdatrie.so.1 => /lib/aarch64-linux-gnu/libdatrie.so.1 (0x0000ffff87b50000)
libbrotlidec.so.1 => /lib/aarch64-linux-gnu/libbrotlidec.so.1 (0x0000ffff87b30000)
libbsd.so.0 => /lib/aarch64-linux-gnu/libbsd.so.0 (0x0000ffff87b00000)
libkeyutils.so.1 => /lib/aarch64-linux-gnu/libkeyutils.so.1 (0x0000ffff87ae0000)
libresolv.so.2 => /lib/aarch64-linux-gnu/libresolv.so.2 (0x0000ffff87ab0000)
libgpg-error.so.0 => /lib/aarch64-linux-gnu/libgpg-error.so.0 (0x0000ffff87a70000)
libbrotlicommon.so.1 => /lib/aarch64-linux-gnu/libbrotlicommon.so.1 (0x0000ffff87a30000)
libmd.so.0 => /lib/aarch64-linux-gnu/libmd.so.0 (0x0000ffff87a10000)
 
Yup, Snagit does this.

My TechSmith account shows a download option for Snagit. It opens up the "Try Snagit for free" page where you can download it. I assume it is just then a matter of entering the license key?
 
My TechSmith account shows a download option for Snagit. It opens up the "Try Snagit for free" page where you can download it. I assume it is just then a matter of entering the license key?
It does but when you buy/upgrade it, they ask for extra $$ for the ability to retain the version and re-download it.
 
  • Like
Reactions: max2
About open source being the key issue - I ran ldd against 1Password and got a long list of libraries. libwebp is not there. 1Password isn't open source software, but ldd still worked. Am I only seeing a partial list because it's not open source? Here's what I see:

What you are seeing here is a list of libraries that 1Password is dynamically linked to when it was compiled. If a library that 1Password needed was not installed on your Linux box or Mac, then the application would fail to start. But this also had me thinking that the latest version of 1Password may already have been recompiled without using the library, or may still have it and other libraries statically linked while still compiling dynamically. I'm leaning towards the former over the latter, as running a file on 1password shows that it is dynamically linked.

BL.
 
What you are seeing here is a list of libraries that 1Password is dynamically linked to when it was compiled. If a library that 1Password needed was not installed on your Linux box or Mac, then the application would fail to start. But this also had me thinking that the latest version of 1Password may already have been recompiled without using the library, or may still have it and other libraries statically linked while still compiling dynamically. I'm leaning towards the former over the latter, as running a file on 1password shows that it is dynamically linked.

BL.

I think I got it. Thanks.

Because BitWarden is open source, we can tell if libwebp is statically linked by reviewing the source. For both 1Password and BitWarden, we can tell if the libraries are dynamically linked with the ldd command.

On my Linux installation, libwebp was patched on 9/13, which has the fix to the vulnerability.
 
I think I got it. Thanks.

Because BitWarden is open source, we can tell if libwebp is statically linked by reviewing the source. For both 1Password and BitWarden, we can tell if the libraries are dynamically linked with the ldd command.

On my Linux installation, libwebp was patched on 9/13, which has the fix to the vulnerability.

That's part of it. The linking is done at compile time. CS201 here. and I'll use the C programming language by default, as this also would apply to C++.

If you compiled a simple "hello world" program in C, the compile process also links the object created by the compilation against the libc library to create the binary. That is done by default without any arguments passed to the compiler. For example:

Bash:
gcc hello.c

will simply create a binary program that prints "hello world", but will have the libraries needed to print that statically linked - embedded - in the binary.

However, if you compiled it dynamically, and added some other functions to it that requires another library to be added:

Bash:
gcc -c hello.c

this will produce an object file called hello.o that is compiled, but not linked to any library to create the binary. To do that, you'd do:

Bash:
gcc -o hello hello.o -lexample

This will create a binary program called hello, that is dynamically linked to the example library.

In Bitwarden's case, by looking at the source, you could see if any header files for the libwebp library are included in any of the files in the source code. If they are, then they are compiled into the program and used, regardless of being dynamically or statically compiled.

BL.
 
  • Like
Reactions: HDFan
That's part of it. The linking is done at compile time. CS201 here. and I'll use the C programming language by default, as this also would apply to C++.

If you compiled a simple "hello world" program in C, the compile process also links the object created by the compilation against the libc library to create the binary. That is done by default without any arguments passed to the compiler. For example:

Bash:
gcc hello.c

will simply create a binary program that prints "hello world", but will have the libraries needed to print that statically linked - embedded - in the binary.

However, if you compiled it dynamically, and added some other functions to it that requires another library to be added:

Bash:
gcc -c hello.c

this will produce an object file called hello.o that is compiled, but not linked to any library to create the binary. To do that, you'd do:

Bash:
gcc -o hello hello.o -lexample

This will create a binary program called hello, that is dynamically linked to the example library.

In Bitwarden's case, by looking at the source, you could see if any header files for the libwebp library are included in any of the files in the source code. If they are, then they are compiled into the program and used, regardless of being dynamically or statically compiled.

BL.

Thanks for that detail. I have, in the distant past, done my share of compiling and linking. My main question was just an initial confusion of how the open source advantage related to the use of ldd, which also works against closed source programs. I think I just read too much into your post.
 
Thanks for that detail. I have, in the distant past, done my share of compiling and linking. My main question was just an initial confusion of how the open source advantage related to the use of ldd, which also works against closed source programs. I think I just read too much into your post.

Ahh.. I probably worded it wrong. ldd helps on a binary, regardless of it being FOSS or closed source, as long as the debugging symbols aren’t stripped. At least that way one can see if the library is being used. With FOSS, we can just look at the code and see if the header file is included or if a call to a function in that library is made.. if it is, then we have our answer..

BL.
 
Last edited:
Have been a habitual purchaser of 1Password licenses for as long as I can remember. I'm still using 1Password 7 on a perpetual license and have now started to migrate to iCloud Passwords. I exported my passwords to .csv file and imported them into iCloud password. This procedure worked very well. Have now turned off the 1password extension in Safari and am testing now. So far the transition has been very smooth. Am slowly transferring my software licenses and secured notes to secured Apple Notes as well.

Will test for a few months. So far it seems like the native iCloud passwords solution seems to be quite robust. Waiting for Sonoma to test out the Chrome extension for iCloud Passwords as that's the only other browser I use occasionally.
I know it's only been a week but I'm wondering how this is going for you and if you'd still recommend it.

I have everything in 1Password, but Apple's password management stuff has become so good (and so aggressive) that I often find that I'm just trying to keep passwords updated in 1Password rather than having them filled from the program. I still have software license details and some other sensitive information in 1Password, but could theoretically do what you're doing and put it elsewhere...

Also hate software subscriptions and have mixed feelings about 1Password no longer prioritizing the Mac/Apple platform. I might still try 1Password 8 when 1Password 7 fully stops working... but don't have great feelings about the whole thing.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.