Firefox36(不具合発生時は35.0.1) Windows7 pro 64bit

登録されているブックマークのfaviconが、
特定の企業サイトのfaviconに書き換わってしまいます。(その特定の企業サイトもブックマーク登録されています)

Firefoxをプロファイルも含め削除した後に、
再インストール、予めバックアップしておいたブックマークデータを使って復旧してみました。

ヘルプに載っているトラブルシューティングも一通り試してみました。

症状は改善されず、無関係のブックマークのfaviconが、特定の企業サイトのfaviconに書き換えられてしまいます。
書き換わるのは1度に多くではなく、気がつけば1つ、2つといった具合にゆっくり増えていきます。
書き換わるタイミングはよく解りません、無関係のブックマークをクリックすると書き換わってしまうこともあれば、勝手に換わっていることもあります。

厳密には、この企業の通常のfaviconと若干デザインが違うfavicon(枠がある…色合いが若干違う等…)が、
他の無関係のfaviconを書き換えていきます。

何故、この特定の企業faviconに書き換わるのか、しかも若干デザインが違うのか、何処に問題があるのか、解っていません。

ここしばらく問題の特定のために、Firefoxの削除と再インストール、復旧を繰り返しています。

再インストールのためにバックアップを取っている、ブックマークのJSONファイルに問題があるのではないかとも考えましたが、
確かfaviconのデータはJSONファイルには記録されていないと思ったので、これも確証がありません。

何も検出はされていませんが、何かマルウェアの仕業でしょうか？

何方か対処法などアドバイスいただけると幸いです、よろしくお願いします。

_________________
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0

faviconは3種類あり得て、サイト側で3種に別のものを指定していることもあるし、サイト側が途中で変えていることもあるし、リダイレクトしていてリダイレクト先では異なる可能性もあります。
http://ja.wikipedia.org/wiki/Favicon
　<link rel="shortcut icon" href="http://example.com/favicon.ico" type="image/vnd.microsoft.icon" />
　 <link rel="icon" href="http://example.com/favicon.ico" type="image/vnd.microsoft.icon" />
　ルートの、favicon.ico
バックアップをしょっちゅうリストアしていれば、サイト側が途中で変えている場合には、おっつけ現在のものに置き換えられるでしょう。

グーグルのサイトのfaviconがYahoo!のものに置き換わってしまう、というような置き換えられ方になるのですか？

そもそも、サイト側のfaviconの指定やfvicon.icoは、どうなっているのですか？(上記のlinkとfavicon.ico)
それらは、HTTP GETでサイトから取得されますが、Webコンソールには、faviconに対するどのようなアクセスが記録されるのですか？
手動で3種に対するurlを入れればそれが表示されますが、それはどのようなデータですか？
ブックマークのものは、本来のサイト側指定のものと、どう異なっているのですか？

あるとすると、ルートのfaviconで、他のサイトのデータの更新をする時に、今アクセスしようとしたブックマークのアイコンを変えてしまう、というような現象かな？
SQLITE_ABORT、SQLITE_ABORT_ROLLBACK問題かもしれない...

その企業のどこかのページでは、通常のfaviconとは若干デザインが違う、枠がある…色合いが若干違うfaviconを使っているのでしょう。
で、他の無関係なサイトのブックマークに保存しているfaviconのデータが、それで書き換えられてしまい、
それが色々なブックマークで次々と起こる、というのは、
そのfaviconに何か特殊性・特異性がありそうに思います。
3種のfaviconが、同じデザインであっても別ファイルで、更新日時が異なるから、アクセスする度に3回の更新が入るとか。
で、しかも、rel="shortcut icon"は別サイト、rel="icon"もそれとはまた別なサイトで、3種ともリダイレクトしまくりとか。

こういったことはないですか？

このような現象は、いつごろから起こり始めたのですか？
Firefoxに含まれるSQLiteのバージョンが、3.7.11より以前のものから、3.7.11より以後のものに切り替わった時、ということだと、SQLiteの仕様変更のせい、という可能性もでてきます。
places.sqliteに保存されているはずのJSONデータ(テキスト)とかBLOBデータ(faviconはこの例)が、取り出すとヌルになっていた、というような報告がBugzillaにありました。
ある行の更新がすっぽ抜けてしまう、というようなことが考えられます。、

places.sqliteの中をちょっと見てみました。
ブックマークは、moz_bookmarksというTable、faviconは、 moz_faviconsというTable、で管理していて、
それぞれは、独立しているみたいです。
で、キーは、moz_bookmarksは、当然ながら、サイトのURL、moz_faviconsは、faviconファイルそのもののURL、です。
となると、faviconの表示は、サイトにアクセスし、
ルートのfavicon.icoのもの、rel="shortcut icon"のもの、rel="icon"のもの、を、moz_faviconsというTableから見つけて、
moz_faviconsにあって期限が切れていなければ使う、ということのようです。

これで、faviconのデータはplaces.sqliteの外に移動しろ、というバグがあった理由がわかりました。
本質的に、ブックマークや履歴とは一切関係ないデータ。

となると、状況としては、
問題となるfaviconをhttps://xxx.yyy.zzz/favicon.icoとして、
そのアイコンとは無関係な、http://www.abc.defというサイトの、ルートのfaviconであるhttp://www.abc.def/favicon.icoをキーに持った、moz_faviconsというTableの行の、
fabiconのデータを保持しているBLOBのカラム(dataという名前)に保持されているデータが、
http://www.abc.def/favicon.icoとは無関係であるはずの、https://xxx.yyy.zzz/favicon.icoのデータになってしまう、
ということになります。

HTTP GET https://xxx.yyy.zzz/favicon.icoで取得したデータを、
moz_faviconsというTableの、http://www.abc.def/favicon.icoをキーにした行に入れてしまう、
というのは、あまりにもお粗末過ぎるコードで、ちょっと考えにくい。
他のサイトのfaviconを次々と置き換えて行く、https://xxx.yyy.zzz/favicon.icoが特殊・特異で、
moz_faviconsというTableの更新の時に、他のサイトのためのデータの更新との競合を次から次へと引き起こしまくり、
その結果、SQLITE_ABORTやSQLITE_ABORT_ROLLBACKが起こっている、
と考えると、説明がつく状況になります。

[ちょっと補足]
ちょっと誤解を招きそうな書き方だったので。
moz_bookmarksやmoz_faviconsなどのTableは、完全に独立しているわけではなく、
サイトのuriはmoz_placesというTableにあって、moz_bookmarksというTableの行からmoz_placesというTableの行をポイント、とうようなことをしていて、一種の正規化のようなことはなされています。
moz_bookmarksとmoz_faviconsの関係も同様で、ブックマークの表示でfaviconを使うために、moz_bookmarksからmoz_faviconsへのポインター・紐付けもあるはずです。
ばっと見では判断がつかないので(guid,global uid?、がそれっぽいですが)、適当に書いてます(^^;
この、moz_bookmarksからmoz_faviconsへのポインター・紐付けがおかしくなる、ということも、十分に考えられます。
ブックマークの表示では、サイトにアクセスしないから、サイトのHTMLのlink rel="icon"などは見なくて、moz_faviconsの行のfaviconファイルのURIは無関係であり、ポイントされた行のfaviconのデータをそのまま使うと思います。
[/ちょっと補足の終わり]

[追記]
Webコンソールには、そのタブのWebサイトに関するアクセスのログが表示されます。
ブックマークの更新などのためのアクセスについては、Browserコンソールを使う必要があります。
[/追記終わり]

どうやって調べたのか書いてありませんが、通常のアンチウィルスソフトでは引っかからないこともあるでしょう。
「マルウェアが引き起こす問題のトラブルシューティング | Firefox ヘルプ」で紹介されているツールを試してみるとよいかと思います。
何らかの不具合で起きている可能性もあるわけですが、まずはブックマークがどうなっているのかを調べ、マルウェアの可能性を潰してしまいましょう。

「履歴とブックマークの管理」（Ctrl+Shift+B）から「インポートとバックアップ」→「バックアップ」を選択するとブックマークをJSON形式のテキストファイルに書き出すことができます。これをテキストエディタで開いてみてください（改行が入っていないので注意）。
fabiconが替わってしまったブックマーク項目を"title"で探して、サイトへの"uri"とfabiconの"iconuri"がどうなっているかを調べてみてください。
もしマルウェアならどこかのサイトを経由してリダイレクトでサイトを開くURIになってるなんてのがありがちです。

_________________
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0

WADAさん返信ありがとうございます。


基本、そのような置き換わり方になります。この置き換わりの場合、知らない間に置き換わっているというケースです。
また…


アクセスしようとブックマークをクリックすることで書き換わってしまうこともあります(カーソルでフォーカスしただけで変わる場合があります)
faviconが指定されているサイトのアイコンは、クリック(フォーカス)することで変化することがあっても、再度アクセス…クリックすると大抵は元に戻ります。

faviconが指定されていないサイトは、変化してしまうとクリックしても元に戻りません。


Webコンソール、Browserコンソールについては今まで使用したことがなく、
faviconに対するアクセスログを見つけることができませんでした…
サイトのソースから手動で取得してみましたが、TOPページは1種類しか見つけることが出来ませんでした。
取得したアイコンは他を書き換えてしまうアイコンと見え方が(おそらく)一致していました。

実際は複数種類あるのではなくて、背景が透過していないものと、透過している違いなのかもしれません。

本来は登録すると背景が透過しているfaviconが表示されて、
書き換えてしまうfaviconは透過されず、背景が白い(それと…枠があるようにみえる？)という違いのような気がします。




正確には覚えていないのですが、症状が出たのは記憶では2月中ごろだったと思います。この2週間以内かと思います。
SQLiteに関しては…すみません…わかりません(＾＾：

企業名を載せることが適切かどうか何となく迷っていたのですが、
書き換えてしまうfaviconというのはlivedoor.comのfaviconです。
livedoor.comのトップページのfaviconです。

livedoor.comのfaviconに特殊性や特異性があったとして、
他のユーザーの方も同じ現象が現れているような気がするのですが…

places.sqliteの中身については、
記事を何度も読み返して勉強中です(＾＾;
moz_bookmarksからmoz_faviconsへのポインター・紐付けがおかしくなることが十分に考えられるということですね。

Firefoxの削除と復元を繰り返しても症状が続くのを考えると、
一貫して使用しているブックマークのバックアップJSONファイルが破損しているような気もするのですが…(JSONファイル内のlivedoorの部分が？)

やはりlivedoor.comのfaviconが特異で、それが引き金になって不具合が出ているのでしょうか。
その場合はFirefoxの削除といった対処は意味が無いので、今の状況の説明はつくのですが、。

_________________
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0

EarlgreyTeaさん御回答ありがとうございます。

マルウェアの感染の有無は「ESET SMART SECURITY 7」「windows defender」で調べました。
上記のセキュリティソフトに関しては何も検出はされませんでした。


ブックマークのJSONファイルを開いてみるという発想が抜け落ちていました…。


書き換わったfaviconは現在は1つも残っていないのですが、痕跡が残っているのかもしれないので早速調べてみます。
(クリックで元に戻る場合があるのです)また忘れた頃に書き換わると思われますので随時調べてみます。

マルウェアに関してもFirefoxヘルプにあるような、他の駆除ツールを試してみます。

_________________
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0

サイトの特異性・特殊性、はありますね。
link relはほぼこれみたいですが、
　<link rel="icon" href="http://parts.news.livedoor.com/img/favicon.ico?v=20131002" type="image/x-icon">
ルートやディレクトリーのfavicon.icoは、あったりなかったり。
http://news.livedoor.com/
　http://news.livedoor.com/favicon.ico　あり
http://news.livedoor.com/topics/category/main/　(主要、主要ニュース)
　http://news.livedoor.com/topics/category/main/favicon.ico　なし
そして、http://news.livedoor.com/topics/category/main/favicon.ico　に行こうとすると、
エラーメッセージを301で返してリダイレクトし、
http://www.livedoor.com/?utm_source=news&utm_medium=rd　に飛ばします。
　なお、ここでは、<link rel="shortcut icon" href="/img/ie9/favicon.ico">
これって、topics/category/main/favicon.ico に、text/htmlのデータを返してきたのと同じ。

http://news.livedoor.com/favicon.ico
http://www.livedoor.com/img/ie9/favicon.ico
http://parts.news.livedoor.com/img/favi ... v=20131002
を別のタブに開いておいて、topics/category/main/favicon.icoに行こうとして、他に飛ばされる、をやると、
タブの中のico画像の表示が空白になる。
タブのスイッチを何度か行うと戻るから、メモリー上のデータが消され、リフローでキャッシュのデータを取りに行った？

壊す側のライブドアの、ブックマークしてあるサイトのURL、link rel,ルートのfavicon.ico、などはどうなっているのですか？

「置き換えられる」のは、どこの何ですか？
壊される側の、ブックマークのアイコン、タブに表示している時のアイコン、タブに表示したアイコンファイル、等々。
また、壊される側の、link rel、ルートのfavicon、はどうなっていますか？


link relによるかルートのfavicon.icoによるか、で症状がことなるみたいですね。
link relだと、ブックマークからfaviconデータの行へのポインターがあるが、ルートのfvicon.icoからの場合は、単にキャッシュから持ってこられる、というような違いがある？

一度置き換えられた後、何もしないで終了、places.sqliteのバックアップをとる、再起動してブックマークを表示、をした時も、置き換えられたままですか？
バックアップのplaces.sqliteの中身も壊れている状態ですか。
ライブドアのルートのfavicon.icoでリダイレクトされてtext/htmlを返されるとキャッシュが壊れ、キャッシュから表示しているブックマークのアイコンが影響を受ける、というようなことも考えられます。

私も、ルートのfavicon.ocoに対するHTTP GETを、Broweserコンソール、Webコンソールで見ることができず...

http://www.h2.dion.ne.jp/~radon/index.html で、HTMLには、link rel="icon"なし、link rel="shortcut icon"なしで、
http://www.h2.dion.ne.jp/~radonは、個人用に割り当てられたディレクトリーなので何もおけず、
従って、ルートのhttp://www.h2.dion.ne.jp/favicon.icoは存在せず、
念のために、http://www.h2.dion.ne.jp/~radon/favicon.icoを置く、という状態で、
browser.shell.shortcutFavicons ＝ true (デフォールトのまま)
browser.chrome.favicons = true (デフォールトのまま)
で、Firefox 36.0, Firefox 38.0a1、アクセスしてみたのですが、
ルートのhttp://www.h2.dion.ne.jp/favicon.ico に対するHTTP GETを見ることができず...

ルートではないfavicon.icoに対して、404でhtmlを返すとか、30xでリダイレクト、は、普通に行われているし、
中には、ルートのfavicon.icoを、中身はicoデータでも、Content-Type=text/htmlで返すところがあったりして、
でも、そのサイトは、link rel="shortcut icon"を指定してあって、
places.sqlliteの中では、mime-type=text/htmkではなくてmime-type=image/xxxとかになっていたり、とかあって、
サイトがfaviconデータとして少々変なデータを返したって、そう簡単におかしくなるはずがない、と思えてきました。

で、浮上してきたのが、ルートのfavicon.icoを見に行かない。
これだと、HTMLでfaviconの指定がないとブックマークのアイコンがなくなったり変えられて、サイトに飛んでもアイコンが表示されない、という現象とも合致しそうです。
起動から全部のHTTPについてNSPRログをとらないと、ルートのfavicon.icoにHTTP GETがでない、という確証は得られませんけどね。

ルートのfavicon.icoにHTTP GETがでない、とすると、
(A) ルートのfavicon.icoがあって、link rel="icon"か"shortcut icon"があるサイトで、ルートのfavicon.icoとは異なる、あるいは、ルートのfavicon.icoと同じ、
(B) ルートのfavicon.icoがあって、link rel="icon"か"shortcut icon"が無いサイト、
という違いで、現象が変るのかもしれません。

ブックマークの構造は、bookmarkのTableの行のカラムで、placesのTableの行のidをポイント、
placesのTableの行がサイトのuriiを保持し、placesのTableの行のカラムで、faviconのTableの行のidをポイント、
faviconのTableの行がfaviconのuriiを保持し、faviconのデータを保持、
といった感じのようです。
(C) 以前のバージョンで、
(C-1) 先にルートのfavicon.icoを見ていて、placesのTableでは、faviconのTableの、ルートのfavicon.icoがある行のidをポイントする、
(C-2) link rel があっても、ブックマークとしては既にfaviconのありかを知っているから、何もしない、
だとすると、
以下のようなことが起こるかもしれません。
(D) 新しいバ－ジョンで、ルートのfavicon.icoを見に行かないとすると、
(D-1) faviconのTableに登録された、ルートのfavicon.icoが期限切れになった後、
　　　ルートのfavicon.icoを読みにいかないので、いずれ消されて、そのidが無くなる、
(D-2) 他のサイトで、ブックマーク・faviconの状況が変り、(D-1)のidが再利用される。
　　　Livedoorは、ルートのfavicon.ico ！＝ link rel だから、link rel のfaviconが追加されることになり、
　　　(D-1)で使っていたidの再利用、が起こりやすい。
　　　⇒　Livedoorによる、アイコンのハイジャック　
(D-3) アイコンをハイジャックされたサイトにlink relがあれば、次回のアクセスでfaviconは復活するが、
　　　link relがなくてルートのfavicon.icoで表示されていたものは、復活しない。
(E) そして、Livedoorは、ルートのfavicon.ico ！＝ link rel であり、
　　link rel で指定しているfaviconをいくつも指定してあるので、
　　(ちょっとアクセスしただけで2種類発見、ルートとあわせると、少なくとも3種類存在)、
　　(D-2)のハイジャックを何度も引き起こす。

ルートのfavicon.ico　⇒　link rel="icon/shortcut icon"への自動切換えが起こっていて、
「ルートのfavicon.ico ！＝link rel && link relでfaviconをいくつも指定」のサイトが、ちょっと悪さをして、
今時、まだ「link rel無しでルートのfavicon.ico」のサイトのアイコンが無くなった、
という感じかも。

(F) 以降は、「link rel無しでルートのfavicon.ico派のサイト」のアイコン以外の問題はなくなるはずだが、
　　以前のバックアプから戻す、を何度も行っているので、
　　上記の(D)/(E)の現象を、何度でも繰り返して見られる、と。

places.sqlite の中の、moz_bookmarks, moz_places, moz_favicons というTableの、
この、MozillaZine.jpのMozilla Firefoxフォーラムのブックマークの行のデータを貼っておきますね。
構造は、エクセルの表と全く変りません。

新規プロファイルで、Firefoxが事前定義しているブックマークを全部消してしまい、アイコンのあるブックマークは一つだけ、にしてあるから、moz_faviconsの中には行が一つしかなくて、
favicon_id = "1" を持つmoz_placesの行のid(==24)
⇒　fk = "24" を持つmoz_bookmarksの行、と、逆にだどるだけで、楽。
moz_bookmarks　⇒, moz_places　⇒, moz_faviconsと、順方向にたどると、行が一杯あって、カラムも一杯あって、わかりづらいですけどね。
ブックマークの名前がmoz_bookmarksのtitle欄にでますから、名前の先頭に###をつけるなどしてアイキャッチャーを入れておけば、たくさんあっても簡単にたどれるでしょう。 、

もしも、前のコメントで書いたようなことならば、再現性はあるし、少なくとも数人のところで起こっても良さそう、と思って、Bugzilla.Mozilla.Orgでサマリーに「favicon.ico」がある、比較的最近のものを検索してみたら、以下のものがひっかかってきた。
https://bugzilla.mozilla.org/show_bug.cgi?id=1061456
　「/favicon.ico doesn't work without <link rel="shortcut icon" href="…"> anymore 」
https://bugzilla.mozilla.org/show_bug.cgi?id=1091079
　「favicon.ico isn't being set」
ビンゴ？

ルートのfavicon.icoはあるけれど、HTMLにはlink rel="icon/shortcut icon"が無いサイトを、どなたかご存知ないですか？

[追記1]
バグに書いてあった(^^;
http://habrahabr.ru/ に、renk rel="icon/shortcut icon"なし。
http://habrahabr.ru/favicon.ico はある。
Browserコンソール、Webコンソールで、ルートの/favicon.icoへのアクセスは見られない。
タブにアイコンが表示されない。
しかし、ルートの/favicon.icoを表示したりサイトをまた見たりした後、ブックマークに登録したら、ブックマークにアイコンが表示され、タブにもアイコン表示されていた。
placesのuriは、http://habrahabr.ru/ だし、faviconのuriも http://habrahabr.ru/favicon.ico になっている。
どうなっているんだろう。JavaScriptでやっている？
[/追記1の終わり]
[追記1の補足]
新規プロファイルで http://habrahabr.ru/ で、タブのアイコンもブックマークのアイコンも、ちゃんと表示されます。
つまり、Bug 1061456は再現せず。
そんなに派手ではないから、最初は表示されていないと思ってしまったようです。
Browserコンソールに/favicon.icoへのアクセスがでないのは、単に、FavIconを管理する機能がBrowserコンソールに書いていないだけなんでしょう。
LiveHTTPHeadersやNSPRのhttp:5のログと似たようなものを期待したのが、アホでした(^^;`
となると、複数のページが同じfaviconを使用した時の問題が浮上...
[/追記1の補足の終わり]
[追記1の補足の補足]
癪だから、nsHttp:5でNSPRログをとって確認してみました。
ちゃんとhttp://habrahabr.ru/favicon.icoに対してHTTP GETがだされ、Disk Cacheにも書かれていました。
途中の、内部のリクエストでは、uri=http://habrahabr.ru/favicon.ico#-moz-resolution=16,16ですから、アイコンのためであることは確実。
Bug 1061456 なんぞを信用した私がバカでした。
Livedoorだと、HTTP GETはlink rel="icon"あるいは"shortcut icon"に対してであってルートではないこと、私のページでlink relが無いときには、ちゃんとルートのfavicon.icoにHTTP GETがだされ、404 Not foundが返っていることも確認できました。
最初からNSPRログをとればよかった...
[/追記1の補足の補足の終わり]

[追記2]
どうにも腑におちないので「favicon」だけで検索したら、
https://bugzilla.mozilla.org/show_bug.cgi?id=1051544 「Favicon cache doesn't update history entries with favicon ids」がヒットしてきた。
Bug 1051544 のオープナーさんは、以下のような問題ではないか、といっています。
複数のページが同じfaviconをポイント、は、Livedoorでは当たり前の話だから、関係する？
バグは、AndroidのFirefoxだから、関係ないかな？
[/追記2終わり]

本案件の解決策では無くオフトピ扱いに成りますが、私はこう云う問題の暫定的な解決方法として、AMOに嘗て登録されてた以下のアドオンを利用して凌いで居ます。

* Bookmark Favicon Changer - Sonthakit

尤も、アドオンが対応し無く成った場合は無意味ですが（汗

_________________

＊Windows 10 21H1 64bit/＊GoogleJapaneseInput：ATOK2017：MS-IME
Firefox 95.0：Beta 96：Developer Edition 96：Nightly 97.0a1：
Thunderbird 91.4.0：Earlybird 96：Daily 97.0a1：SeaMonkey 2.53.10/2.58a1：
Opera 82.0.4227.23：Google Chrome 96.0.4664.93/98.0.4756.0（Official Build）canary：
SRWare Iron 96.0.4900.0：Lunascape 6.15.2：Avant Ultimate 2020 build 3, 3.17.2020

一昨日から複数のマルウェア駆除ソフトを使用してみましたが、マルウェアの類は検出されていません。


置き換わった後にplaces.sqliteのバックアップを取って、places.sqliteを削除、再起動すると
faviconは全てクリアになっていて、置き換わっていたブックマークにアクセスしてfaviconを再取得するとそのブックマークは正常なfaviconを取得できます。
但し、他のブックマークが置き換わります。

バックアップしておいたplaces.sqliteに置き換えて起動してみるとやはりfaviconはクリアな状態で、後は上記と同じです。

一度places.sqliteを削除、置換してみるなり、Firefox全体を削除から再インストールしてみるなり、faviconがクリアな状態から取得していく状況のほうが
置き換えられてしまう症状が現れやすいようです。



EE Times Japanのブックマークが書き換わった後に、ブックマークのバックアップJSONファイルを開いてみたところ
"iconuri":"http://eetimes.jp/favicon.ico"
が
"iconuri":"http://portal.profile.livedoor.com/favicon.ico"
に、変化していました。

これでlivedoorの何処のfaviconに書き換わってしまうのか解りました。
「livedoorプロフィール」のfavconらしいのですが、やはり身に覚えの無いサイトです。
アクセスして確認しましたが、ここのfaviconで間違いないようです。

※アクティブになっていないタブがlivedoorTOPのfavicon


EEtimesJapanのfaviconの、書き換わった前後。
※他のブックマークは黒塗りしてあります(モザイクを用意できなかったため)

思い切ってスクリーンショットを用意してみました。
症状はこのようになります…。

_________________
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0

portal.profile.livedoor.com　は、ブックマークには無いんですよね。
となると、ハイジャックの被害に遭うmoz_faviconsの行や使われるfaviconのURIは、ブックマークとは直接関係しない、ということでしょう。

TABLE moz_places, id = "456" , uri = "http:// EE Times Japan のURI",　title = "EE Times Japan"
　　　favicon_id = "789"
があった時に、
TABLE moz_favicons, id = "789" , uri = "http:// EE Times Japan の .ico" , data = "BLOB (EE T.J のもの )"
のuriが、uri = "http://portal.profile.livedoor.com/favicon.ico"　で置き換えられた、ということになります。
その時に、TABLE moz_bookmarks, id = "123" , fk = "456" , title = "EE Times Japanのブックマーク"　があって、ブックマークのアイコンが差し替えられたのが見えた、と。

(A) TABLE moz_favicons, id = "789" が期限切れになて消されて、その直後に、portal.profile.livedoor.comへのアアクセスがあって、moz_favicons, id = "789" が使われた、
という可能性もありますが、portal.profile.livedoor.comに見覚えがないようですし、過去にアクセスしたことがあるというだけであって、可能性は低そうに思います。
複数のmoz_placesの行が、一つの moz_faviconsの行を共有していて、
そのうちの一つのmoz_placesの行を使うブックマーク経由でのサイトのアクセスがあって、
その時に、faviconの上の更新があると、それとは無関係なmoz_faviconsの行を更新してしまう、ということかもしれません。
サイトのfaviconのURLを変えた時に、新規にmoz_faviconsの行を追加してそちらを使いますが、
古い方のfaviconのURLに対応するmoz_faviconsの行を消すわけではありません。
従って、moz_placesの行のどれからもポイントされていないmoz_faviconsの行、というのもあり得ます。

サイトにアクセスすれば、link rel="icon", link rel="ishortcut con", ルートのfavicon.ico,の順に見ていって、必ずHTTP GETを出して、moz_faviconsの行も必要なら更新、のはずで、
その時は、単純に、サイトのURIと一対一対応のmoz_placesの行 ⇒ faviconのURIと一対一対応のmoz_faviconsの行、と辿るはずだから、間違ったmoz_faviconsの行を更新することは、ちょっと考えにくい。

表をつないで考えると、複数のmoz_placesの行が一つの moz_faviconsの行を共有していて、そのうちの一つのmoz_placesの行をブックマークが使用している時には、
　favicon = A, places-A-#1 , bookmarkなし
　favicon = A, places-A-#2 , [ bookmark-A-#2-1, bookmark-A-#2-2 ]
　favicon = A, places-A-#3 , bookmark-A-#3
　favicon = B, places-B , bookmark-B
　favicon = C, placesなし。, bookmarkなし
　favicon = D, places-Ｄ, bookmark-Ｄ
のようになりますが、これを以下のように誤認し、
　favicon = A, places-A-#1 , bookmarkなし
　favicon = B, places-A-#2 , [ bookmark-A-#2-1, bookmark-A-#2-2 ]
　favicon = C, places-A-#3 , bookmark-A-#3
　favicon = D, places-B , bookmark-B
　favicon-= E, places-Ｄ, bookmark-Ｄ
　favicon = F, ...
bookmark-A-#2-2 の更新で、bookmark-A-#2-2 ⇒ places-A-#2 ⇒ favicon = B, が選ばれてしまい、
その時に、ブックマークとは関係ないmoz_placesの行から辿るmoz_faviconsの行のURI/iconデータが使われることもあり得る、
というようなことがあるのかもしれませんね。

単純にこのようなことだけで起こるのなら、Livedoorのサイトにブックマーク経由で行けば、必ずハイジャックしまくりになるはずだから、
もしこのようなことならば、どこかの行のInsertやDeleteが直前か同時に起こる、というようなことが関係すると思います。
moz_faviconsの行の削除は、ブックマークにあるサイトのlink relを変えて、どのmoz_faviconsの行もポイントしていない状態にした程度では起こりません。
ブックマークの管理の中での「定期的な消去」のような内部処理が必要なのでしょう。