Pageviews

Friday, 23 November 2018

Path traversal in mozilla pdf.js

Hi Internet,

Summary: A path traversal issue was observed in Mozilla PDF.js which is a PDF reader in JavaScript. (This issue is unpatched)

This issue was observed while code review of PDF.js (gulpfile.js)

PDF.js is built into version 19+ of firefox and a chrome extension is also available on chrome web store. To install and get a local copy of PDF.js here are the below steps :

Then navigate to http://127.0.0.1:8888/

I've used the attribute --path-as-is from cURL to verify this issue.

This was reported to mozilla via bugzilla but team says "The server with pdf.js is intended to be a development server and should not be exposed to public networks. I suppose we could update the docs to state that." and a upstream issue was filed against this[1].

Thank you

Sunday, 11 November 2018

null-pointer dereference in poppler library - CVE-2018-19149

Hi Internet,

Summary: While fuzzing evince v3.28.4, on linux 4.15.0-38-generic (Ubuntu 18.04 LTS), a null-pointer dereference was observed, initially this was reported to evince but the evince team advised that the issue is in poppler, the library used by evince to render PDF, poppler version: 0.62.0-2ubuntu2.2 is vulnerable to null-pointer dereference, however the issue is already fixed in poppler 0.70, but this will still crash your evince v3.28.4 if poppler is not updated to v.0.70. Fuzzing result showing a very important vulnerability in a package currently shipped by a major Linux distribution is still of interest, even if that Linux distribution does not package the latest released upstream version.

Initially, I started fuzzing with evince which is a document reader which comes by default with most of the linux distribution. Also created a malformed PDF files to provide input to AFL, after a successfully compile of evince with afl-gcc, the final command was,

It took three days to get 21 crashes in which 6 unique crashes where observed, while analyzing the crash with triage_crashes which is one of the component which comes with AFL for analyzing crashes, I observed a null-PTR.

So basically a null-PTR is a type of error which causes a SIGSEGV, segmentation fault to the program, and this usually happens when a program or binary try to read or write to the memory with null-PTR.

I went ahead and reported this to GNOME, because evince is one of there asset, the team says "The issue is in Poppler, the library used by Evince to render PDF" arggh!, so stupid am I, I taught `libpoppler-glib.so` is one of the shared object in evince but didn't know that poppler is a PDF rendering library which comes by default in most of the PDF reader in linux distribution, and there is a standalone repo out there for poppler.

Also, GNOME evince team says "it seems it has already been addressed. See https://gitlab.freedesktop.org/poppler/poppler/merge_requests/93, Nevertheless, if the issue is still present, please file a bug in https://gitlab.freedesktop.org/poppler/poppler/"

Okay no worries, I still went ahead and file a bug in poppler, but the team over there asked me what poppler version am i using, and it was version 0.62.0-2ubuntu2.2 and they said the issue is already fixed in poppler version 0.70 After I read this, I was like....
Img Src: https://knowyourmeme.com/photos/1189534-canada

Pheww!, does that mean, my three days of fuzzing just went = to 0 OR am I actually missing something over here ?

I went back to the stack-trace read it again and also check whether am I fuzzing all the latest build of the binary for sure I was fuzzing the latest build of evince but not poppler. Hmmmmmm! I knew my fuzzing system was fully updated but still just to cross check, I did full apt-get update and upgrade but my poppler version remains the same all the time which is 0.62.0-2ubuntu2.2 strange.

I need a guidance over here, and didn't knew what to do ahead, so I contacted MITRE for this and went for a nap, they suggested - "That a fuzzing result showing a very important vulnerability in a package currently shipped by a major Linux distribution is still of interest, even if that Linux distribution does not package the latest released upstream version. For example, an out-of-bounds write finding is still very useful in that case, but not out-of-bounds read, NULL pointer dereference,divide-by-zero, etc."

Ohhh, I see so the latest version of poppler is still not shipped for most of the linux distribution out there, now i understood the entire concept, later MITRE also helped me by assigning a CVE to this issue which is CVE-2018-19149 - Poppler before 0.70.0 has a NULL pointer dereference in _poppler_attachment_new when called from poppler_annot_file_attachment_get_attachment.

An upstream bug is filed in Ubuntu launchpad to track this issue. 

PS: Its not about collecting CVE's, CVE's are just a reference number to an issue you can point for a vulnerability when you show case it somewhere, rather than pointing it to various post. (Personal opinion).

Lessons learned from this:
1. I didn't know poppler is a library which is used by evince and other PDF reader to render PDF's.
2. I understood how to create a malformed PDF to provide input to AFL while fuzzing.
3. The reply from MITRE helped me to resolve my query.
4. During all this, I also got my hands on hongfuzz

Hope you like the read, view this on oss-security mailing list.


Thank you
Dhiraj

Tuesday, 6 November 2018

Fuzzing IEC 61850 protocol - CVE-2018-18957

Hi Internet,

Summary: While fuzzing(I've used AFL for this), a stack based buffer overflow was found in libIEC61850 (the open-source library for the IEC 61850 protocols) in prepareGooseBuffer in goose/goose_publisher.c and /linux/ethernet_linux.c

Steps to reproduce:
$ ./goose_publisher_example crash_goosecr_stack_smash_overflow_aaaaaaaaa
Using interface crash_goosecr_stack_smash_overflow_aaaaaaaaa
*** stack smashing detected ***:  terminated
Aborted
$
File: crash_goosecr_stack_smash_overflow_aaaaaaaaa
[This file will be expired after 30 days.]

Debugging:
(gdb) run crash_goosecr_stack_smash_overflow_aaaaaaaaa
Starting program:
/home/input0/Desktop/libiec61850/examples/goose_publisher/goose_publisher_example
crash_goosecr_stack_smash_overflow_aaaaaaaaa
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Using interface crash_goosecr_stack_smash_overflow_aaaaaaaaa
*** stack smashing detected ***:  terminated

Program received signal SIGABRT, Aborted.
__GI_raise (sig=sig@...ry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51    ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  __GI_raise (sig=sig@...ry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1  0x00007ffff7805801 in __GI_abort () at abort.c:79
#2  0x00007ffff784e897 in __libc_message (action=action@...ry=do_abort,
fmt=fmt@...ry=0x7ffff797b988 "*** %s ***: %s terminated\n")
    at ../sysdeps/posix/libc_fatal.c:181
#3  0x00007ffff78f9cd1 in __GI___fortify_fail_abort
(need_backtrace=need_backtrace@...ry=false,
    msg=msg@...ry=0x7ffff797b966 "stack smashing detected") at
fortify_fail.c:33
#4  0x00007ffff78f9c92 in __stack_chk_fail () at stack_chk_fail.c:29
#5  0x000055555555a211 in Ethernet_getInterfaceMACAddress
(interfaceId=0x7fffffffdeee "crash_goosecr_stack_smash_overflow_aaaaaaaaa",
    addr=0x7fffffffd91c "k_smas\377\377") at
hal/ethernet/linux/ethernet_linux.c:170
#6  0x00005555555594ee in prepareGooseBuffer (self=0x5555557637d0,
parameters=0x7fffffffd9ac,
    interfaceID=0x7fffffffdeee
"crash_goosecr_stack_smash_overflow_aaaaaaaaa") at
src/goose/goose_publisher.c:168
#7  0x0000555555559293 in GoosePublisher_create (parameters=0x7fffffffd9ac,
    interfaceID=0x7fffffffdeee
"crash_goosecr_stack_smash_overflow_aaaaaaaaa") at
src/goose/goose_publisher.c:72
#8  0x0000555555555387 in main (argc=2, argv=0x7fffffffdaa8) at
goose_publisher_example.c:52
(gdb) i r
rax            0x0    0
rbx            0x7fffffffd6b0    140737488344752
rcx            0x7ffff7803e97    140737345765015
rdx            0x0    0
rsi            0x7fffffffd410    140737488344080
rdi            0x2    2
rbp            0x7fffffffd840    0x7fffffffd840
rsp            0x7fffffffd410    0x7fffffffd410
r8             0x0    0
r9             0x7fffffffd410    140737488344080
r10            0x8    8
r11            0x246    582
r12            0x7fffffffd6b0    140737488344752
r13            0x1000    4096
r14            0x0    0
r15            0x30    48
rip            0x7ffff7803e97    0x7ffff7803e97 <__gi_raise>
eflags         0x246    [ PF ZF IF ]
cs             0x33    51
ss             0x2b    43
ds             0x0    0
es             0x0    0
fs             0x0    0
gs             0x0    0
(gdb)
SRC:
Snip : src/goose/goose_publisher.c
{
    GoosePublisher self = (GoosePublisher) GLOBAL_CALLOC(1, sizeof(struct sGoosePublisher));
    prepareGooseBuffer(self, parameters, interfaceID);
    self->timestamp = MmsValue_newUtcTimeByMsTime(Hal_getTimeInMs());
    GoosePublisher_reset(self);
    return self;
}
Snip: src/goose/goose_publisher.c
    if (interfaceID != NULL)
        Ethernet_getInterfaceMACAddress(interfaceID, srcAddr);
    else
Ethernet_getInterfaceMACAddress(CONFIG_ETHERNET_INTERFACE_ID, srcAddr);
Snip: /linux/ethernet_linux.c
strcpy(buffer.ifr_name, interfaceId);
Later CVE-2018-18957 was assigned to this issue, Read this on oss-security.


Thank you
Dhiraj

Thursday, 18 October 2018

Porting CVE-2018-8120 to an MSF module

Hi Internet,

#Shortpost
I have added the support of CVE-2018-8120 to MSF module, before porting this to MSF I read through the analysis of the issue.

After reading the blog post of xiaodaozhi I understood CVE-2018-8120 happens because of a null pointer dereference in the win32k kernel module at start this would lead to BSOD in vulnerable systems, however the exploit code was written in such a fashion that would override the function pointer which is present in kernel mode that achieves escalation of privilege to the remote or your local system.

It took me a while to port this to an MSF module also I would like to thank MSF team for there review's done during that time, at last this was successfully ported and landed!

The path for this module will be `exploit/windows/local/ms18_8120_win32k_privsec.rb` view this in action. (Sweeeeeeet!)
 
This module was tested against windows 7 x64 and x86 based systems and windows server 2008 R2 x64. However this vulnerability impacts following software versions or editions which are affected.
Reference: https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2018-8120



Thank you
Dhiraj

Saturday, 29 September 2018

Telegram anonymity fails in desktop - CVE-2018-17780

Hi Internet,

Summary: Strangely tdesktop 1.3.14 and Telegram for windows (3.3.0.0 WP8.1) leaks end user private and public IP address while making calls. This bug was awarded €2000 by Telegram security team. (Sweeet..)
Img Src: https://telegram.org/img/tl_card_synchronize.gif
Telegram is supposedly a secure messaging application, but it forces clients to only use P2P connection while initiating a call, however this setting can also be changed from "Settings > Privacy and security > Calls > peer-to-peer" to other available options. The tdesktop and telegram for windows breaks this trust by leaking public/private IP address of end user and there was no such option available yet for setting "P2P > nobody" in tdesktop and telegram for windows.

PS: Even telegram for android will also leak your IP address if you have not set "Settings > Privacy and security > Calls > peer-to-peer > nobody" (But Peer-to-Peer settings for call option already exists in telegram for android).

To view this in action in tdesktop:
1. Open tdesktop,
2. Initiate a call to anyone,
3. You will notice the end user IP address is leaking.
 

Other scenario:
1. Open tdesktop in Ubuntu and login with user A
2. Open telegram in windows phone login with user B
3. Let user B initiate the call to user A
4. While user A access log will have public/private IP address of user B.
Not only the MTProto Mobile Protocol fails here in covering the IP address, rather such information can also be used for OSINT. This issue was fixed in 1.3.17 beta and v1.4.0 which have an option of setting your "P2P to Nobody/My contacts", Later CVE-2018-17780 was assign to this vulnerability.


Regards

Thursday, 27 September 2018

Telegram uses SOCKS5 to share user/creds

Hi Internet,

Summary: Telegram is supposedly is a secure messaging application but it uses SOCKS5 to transmit user credential's, neither traffic nor credentials are encrypted in the SOCKS5 protocol, but this is how the SOCKS protocol works (see https://tools.ietf.org/html/rfc1929), SOCKS5 carries passwords in cleartext. Telegram team is aware with this and says its working has intended.
Img Src: https://telegram.org/img/tl_card_open.gif

Product affected: tdesktop 1.3.16 alpha, Browser Info: Firefox 62.0 (64 bit), Tested on: Ubuntu 18.04 LTS x64

Steps to reproduce the issue:
1. Open tdesktop
2. Go to Settings > Advanced Settings > Connection type
3. Open "Proxy Settings" check "Use proxy"
4. Put some random Hostname, Port, Username and Password
5. tdesktop tries to connect it, while it connects click on that line which is made of 3 small spots (On right hand side)
6. Click share, the link gets copied.

Example Link: https://t.me/socks?server=inputzero.io&port=22&user=dhiraj&pass=MystrongPassw0rd 

The link which gets generated have the password in plaintext, SOCKS5 is a transport protocol and by itself it is not encrypted. Requests transmitting such  credentials in plain text are considered as a bad security practice.

However, the URL which gets generated via telegram is in HTTPS but, URI producers should not provide a URI that contains a username or password that is intended to be secret.  URIs are frequently displayed by browsers, stored in clear text bookmarks, and logged by user agent history and intermediary applications (proxies).

Read this on oss sec-lists. Later CVE-2018-17613 was assigned to this issue.

Regards

Sunday, 16 September 2018

The Secrets of Tez

Hi Internet,

Summary: The Google Pay (Tez) apps leaks end users email address, this issue was marked as WONTFIX by google.
Img Src: https://www.kisspng.com/png-tez-unified-payments-interface-google-apps-701156/preview.html

You might be aware of different technique for extracting email from LinkedIn similarly Tez app allow you to do so.

Steps to reproduce:
1. Open Tez,
2. Click on New,
3. You will see "Google Pay Connections",
4. Click on any one contact.
5. Their respective email address will be displayed.


In this case, I have never had email of "Ajay" I just had his contact saved. However in the similar fashion, I can view email address of  all the people in my contacts if they are on Tez. However it is not necessary to initiate the payment to get his/her email you can simply view it. (If user is already added in contact).

This issue was submitted to google but was marked WONTFIX, google says "Thanks for report! We think the issue might not be severe enough for us to track it as a security bug."

This is not such great bug but, such data can be use in OSINT to perform targeted attack on victim, hope you like the read.

Regards

Monday, 3 September 2018

An untold story of skype by microsoft

Hi Internet,

Summary: It was observed that the skype has a malloc(): memory corruption bug while you share some media/file with someone during a call.

Tested on: Linux zero 4.15.0-29-generic #31-Ubuntu SMP Tue Jul 17 15:39:52 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux (Ubuntu 18.04 LTS)
Product affected: Skype for linux (skypeforlinux_8.27.0.85_amd64.deb)

Steps to reproduce this issue:
1. Open Skype
2. Call anyone
3. During the call try sharing the media or files to the same person
4. The Skype  gets crash.

While on a call with one of my colleague, I tried sharing a file which froze my skype and then it gets crash. However moving further I tried to debug it with `gdb` and this is what i got.
$ *** Error in `/snap/skype/51/usr/share/skypeforlinux/skypeforlinux --executed-from=/home/input0 --pid=6896': malloc(): memory corruption: 0x000000000641ff80 ***
======= Backtrace: =========
/snap/core/current/lib/x86_64-linux-gnu/libc.so.6(+0x777e5)[0x7fb57d6b97e5]
/snap/core/current/lib/x86_64-linux-gnu/libc.so.6(+0x8213e)[0x7fb57d6c413e]
/snap/core/current/lib/x86_64-linux-gnu/libc.so.6(__libc_malloc+0x54)[0x7fb57d6c6184]
/snap/skype/51/usr/share/skypeforlinux/skypeforlinux --executed-from=/home/input0 --pid=6896(malloc+0x1c)[0x47cc34c]
/snap/skype/51/usr/share/skypeforlinux/../../../lib/x86_64-linux-gnu/libglib-2.0.so.0(g_malloc+0x19)[0x7fb57ff91719]
/snap/skype/51/usr/share/skypeforlinux/../../../lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x8508d)[0x7fb57ffc708d]
/snap/skype/51/usr/share/skypeforlinux/../../../lib/x86_64-linux-gnu/libglib-2.0.so.0(g_variant_get_data+0x1f)[0x7fb57ffc72ff]
/snap/skype/51/usr/share/skypeforlinux/../../../lib/x86_64-linux-gnu/libglib-2.0.so.0(g_variant_get+0xda)[0x7fb57ffc610a]
/usr/lib/x86_64-linux-gnu/gio/modules/libgioremote-volume-monitor.so(+0xc873)[0x7fb57314b873]
/usr/lib/x86_64-linux-gnu/gio/modules/libgioremote-volume-monitor.so(+0x10f2e)[0x7fb57314ff2e]
/usr/lib/x86_64-linux-gnu/gio/modules/libgioremote-volume-monitor.so(+0x11dcb)[0x7fb573150dcb]
/snap/skype/51/usr/share/skypeforlinux/../../lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x15ad8)[0x7fb5824c3ad8]
/snap/skype/51/usr/share/skypeforlinux/../../lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_object_newv+0xd1)[0x7fb5824c4c01]
/snap/skype/51/usr/share/skypeforlinux/../../lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_object_new+0x104)[0x7fb5824c5534]
/snap/skype/51/usr/share/skypeforlinux/../../lib/x86_64-linux-gnu/libgio-2.0.so.0(g_volume_monitor_get+0x7c)[0x7fb582798ebc]
/snap/skype/51/usr/share/skypeforlinux/../../lib/x86_64-linux-gnu/libgtk-3.so.0(+0x25c3d5)[0x7fb583ba53d5]
/snap/skype/51/usr/share/skypeforlinux/../../lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_type_create_instance+0x1f9)[0x7fb5824e1359]
/snap/skype/51/usr/share/skypeforlinux/../../lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x1531b)[0x7fb5824c331b]
/snap/skype/51/usr/share/skypeforlinux/../../lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_object_newv+0xd1)[0x7fb5824c4c01]
/snap/skype/51/usr/share/skypeforlinux/../../lib/x86_64-linux-gnu/libgtk-3.so.0(+0x11a75a)[0x7fb583a6375a]
/snap/skype/51/usr/share/skypeforlinux/../../lib/x86_64-linux-gnu/libgtk-3.so.0(+0x11ce73)[0x7fb583a65e73]
/snap/skype/51/usr/share/skypeforlinux/../../../lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x4d5a3)[0x7fb57ff8f5a3]
/snap/skype/51/usr/share/skypeforlinux/../../../lib/x86_64-linux-gnu/libglib-2.0.so.0(g_markup_parse_context_parse+0xfc3)[0x7fb57ff90763]
/snap/skype/51/usr/share/skypeforlinux/../../lib/x86_64-linux-gnu/libgtk-3.so.0(+0x11d8d6)[0x7fb583a668d6]
/snap/skype/51/usr/share/skypeforlinux/../../lib/x86_64-linux-gnu/libgtk-3.so.0(gtk_builder_extend_with_template+0x1a8)[0x7fb583a61b78]
/snap/skype/51/usr/share/skypeforlinux/../../lib/x86_64-linux-gnu/libgtk-3.so.0(gtk_widget_init_template+0x107)[0x7fb583cabe07]
/snap/skype/51/usr/share/skypeforlinux/../../lib/x86_64-linux-gnu/libgtk-3.so.0(+0x1ae4f1)[0x7fb583af74f1]
/snap/skype/51/usr/share/skypeforlinux/../../lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_type_create_instance+0x1f9)[0x7fb5824e1359]
/snap/skype/51/usr/share/skypeforlinux/../../lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x1531b)[0x7fb5824c331b]
/snap/skype/51/usr/share/skypeforlinux/../../lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_object_newv+0xd1)[0x7fb5824c4c01]
/snap/skype/51/usr/share/skypeforlinux/../../lib/x86_64-linux-gnu/libgtk-3.so.0(+0x11a75a)[0x7fb583a6375a]
/snap/skype/51/usr/share/skypeforlinux/../../lib/x86_64-linux-gnu/libgtk-3.so.0(+0x11bb65)[0x7fb583a64b65]
/snap/skype/51/usr/share/skypeforlinux/../../lib/x86_64-linux-gnu/libgtk-3.so.0(+0x11d4f1)[0x7fb583a664f1]
/snap/skype/51/usr/share/skypeforlinux/../../../lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x4d6d7)[0x7fb57ff8f6d7]
/snap/skype/51/usr/share/skypeforlinux/../../../lib/x86_64-linux-gnu/libglib-2.0.so.0(g_markup_parse_context_parse+0xd8e)[0x7fb57ff9052e]
/snap/skype/51/usr/share/skypeforlinux/../../lib/x86_64-linux-gnu/libgtk-3.so.0(+0x11d8d6)[0x7fb583a668d6]
/snap/skype/51/usr/share/skypeforlinux/../../lib/x86_64-linux-gnu/libgtk-3.so.0(gtk_builder_extend_with_template+0x1a8)[0x7fb583a61b78]
/snap/skype/51/usr/share/skypeforlinux/../../lib/x86_64-linux-gnu/libgtk-3.so.0(gtk_widget_init_template+0x107)[0x7fb583cabe07]
/snap/skype/51/usr/share/skypeforlinux/../../lib/x86_64-linux-gnu/libgtk-3.so.0(+0x1a773e)[0x7fb583af073e]
/snap/skype/51/usr/share/skypeforlinux/../../lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_type_create_instance+0x1f9)[0x7fb5824e1359]
/snap/skype/51/usr/share/skypeforlinux/../../lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x1531b)[0x7fb5824c331b]
/snap/skype/51/usr/share/skypeforlinux/../../lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_object_new_valist+0x3b5)[0x7fb5824c51b5]
/snap/skype/51/usr/share/skypeforlinux/../../lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_object_new+0xf1)[0x7fb5824c5521]
/snap/skype/51/usr/share/skypeforlinux/../../lib/x86_64-linux-gnu/libgtk-3.so.0(gtk_file_chooser_dialog_new+0x74)[0x7fb583af1294]
/snap/skype/51/usr/share/skypeforlinux/skypeforlinux --executed-from=/home/input0 --pid=6896[0x4e3b90b]
/snap/skype/51/usr/share/skypeforlinux/skypeforlinux --executed-from=/home/input0 --pid=6896(_ZN11file_dialog14ShowOpenDialogERKNS_14DialogSettingsERKN4base8CallbackIFvbRKSt6vectorINS3_8FilePathESaIS6_EEELNS3_8internal8CopyModeE1ELNSC_10RepeatModeE1EEE+0x2d)[0x4e3be3d]
/snap/skype/51/usr/share/skypeforlinux/skypeforlinux --executed-from=/home/input0 --pid=6896(_ZN4atom15WebDialogHelper14RunFileChooserEPN7content15RenderFrameHostERKNS1_17FileChooserParamsE+0x33c)[0x4e4d90c]
/snap/skype/51/usr/share/skypeforlinux/skypeforlinux --executed-from=/home/input0 --pid=6896[0x1d8c9b4]
/snap/skype/51/usr/share/skypeforlinux/skypeforlinux --executed-from=/home/input0 --pid=6896[0x1d8c858]
/snap/skype/51/usr/share/skypeforlinux/skypeforlinux --executed-from=/home/input0 --pid=6896[0x1d86c2f]
/snap/skype/51/usr/share/skypeforlinux/skypeforlinux --executed-from=/home/input0 --pid=6896[0x2347525]
/snap/skype/51/usr/share/skypeforlinux/skypeforlinux --executed-from=/home/input0 --pid=6896[0x48001eb]
/snap/skype/51/usr/share/skypeforlinux/skypeforlinux --executed-from=/home/input0 --pid=6896[0x47ed9db]
/snap/skype/51/usr/share/skypeforlinux/skypeforlinux --executed-from=/home/input0 --pid=6896[0x47edcf8]
/snap/skype/51/usr/share/skypeforlinux/skypeforlinux --executed-from=/home/input0 --pid=6896[0x47ee0d1]
/snap/skype/51/usr/share/skypeforlinux/skypeforlinux --executed-from=/home/input0 --pid=6896[0x47c4159]
/snap/skype/51/usr/share/skypeforlinux/skypeforlinux --executed-from=/home/input0 --pid=6896[0x47affc0]
/snap/skype/51/usr/share/skypeforlinux/skypeforlinux --executed-from=/home/input0 --pid=6896[0x1bfef9e]
/snap/skype/51/usr/share/skypeforlinux/skypeforlinux --executed-from=/home/input0 --pid=6896[0x1bfed9e]
/snap/skype/51/usr/share/skypeforlinux/skypeforlinux --executed-from=/home/input0 --pid=6896[0x1d65ead]
/snap/skype/51/usr/share/skypeforlinux/skypeforlinux --executed-from=/home/input0 --pid=6896[0x1e67b93]
/snap/skype/51/usr/share/skypeforlinux/skypeforlinux --executed-from=/home/input0 --pid=6896[0x1a4c63c]
/snap/skype/51/usr/share/skypeforlinux/skypeforlinux --executed-from=/home/input0 --pid=6896[0x19e6d0d]
======= Memory map: ========
000dc000-00200000 rw-p 00000000 07:15 15088                              /snap/skype/51/usr/share/skypeforlinux/skypeforlinux
00200000-01802000 r--p 00124000 07:15 15088                              /snap/skype/51/usr/share/skypeforlinux/skypeforlinux
01802000-04f35000 r-xp 01726000 07:15 15088                              /snap/skype/51/usr/share/skypeforlinux/skypeforlinux
04f35000-04f4b000 rw-p 04e59000 07:15 15088                              /snap/skype/51/usr/share/skypeforlinux/skypeforlinux
04f4b000-05818000 rw-p 00000000 00:00 0 
06322000-0749a000 rw-p 00000000 00:00 0                                  [heap]
af8f00000-af8f80000 rw-p 00000000 00:00 0 
2a231d00000-2a231d80000 rw-p 00000000 00:00 0 
4342f600000-4342f6ab000 rw-p 00000000 00:00 0 
4dab7f00000-4dab800a000 rw-p 00000000 00:00 0 
5e2b1980000-5e2b1a00000 rw-p 00000000 00:00 0 
683f0500000-683f0580000 rw-p 00000000 00:00 0 
74c45800000-74c45880000 rw-p 00000000 00:00 0 
7f95e280000-7f95e300000 rw-p 00000000 00:00 0 
8590f380000-8590f400000 rw-p 00000000 00:00 0 
a95ac180000-a95ac200000 rw-p 00000000 00:00 0 
b464c9b8000-b464c9c0000 rw-p 00000000 00:00 0 
b464c9c0000-b464c9c4000 ---p 00000000 00:00 0 
bf52cd00000-bf52cd80000 rw-p 00000000 00:00 0 
c191e080000-c191e100000 rw-p 00000000 00:00 0 
fe78f400000-fe78f480000 rw-p 00000000 00:00 0 
14c588080000-14c588100000 rw-p 00000000 00:00 0 
16dfa8300000-16dfa8380000 rw-p 00000000 00:00 0 
1b328cb00000-1b328cb80000 rw-p 00000000 00:00 0 
1de101180000-1de101200000 rw-p 00000000 00:00 0 
1e993f000000-1e993f080000 rw-p 00000000 00:00 0 
20c071f00000-20c071f80000 rw-p 00000000 00:00 0 
20c61d680000-20c61d700000 rw-p 00000000 00:00 0 
2240c1900000-2240c19ab000 rw-p 00000000 00:00 0 
22628d700000-22628d780000 rw-p 00000000 00:00 0 
25bf77500000-25bf77580000 rw-p 00000000 00:00 0 
26ce1a280000-26ce1a300000 rw-p 00000000 00:00 0 
26daf9ead000-26daf9f00000 ---p 00000000 00:00 0 
26daf9f00000-26daf9f03000 rw-p 00000000 00:00 0 
26daf9f03000-26daf9f04000 ---p 00000000 00:00 0 
26daf9f04000-26daf9f2d000 rwxp 00000000 00:00 0 
26daf9f2d000-26daf9f80000 ---p 00000000 00:00 0 
26daf9f80000-26daf9f83000 rw-p 00000000 00:00 0 
26daf9f83000-26daf9f84000 ---p 00000000 00:00 0 
26daf9f84000-26daf9fad000 rwxp 00000000 00:00 0 
26daf9fad000-26dafa000000 ---p 00000000 00:00 0 
26dafa000000-26dafa003000 rw-p 00000000 00:00 0 
26dafa003000-26dafa004000 ---p 00000000 00:00 0 
26dafa004000-26dafa02d000 rwxp 00000000 00:00 0 
26dafa02d000-26dafa080000 ---p 00000000 00:00 0 
26dafa080000-26dafa083000 rw-p 00000000 00:00 0 
26dafa083000-26dafa084000 ---p 00000000 00:00 0 
26dafa084000-26dafa0ff000 rwxp 00000000 00:00 0 
26dafa0ff000-26dafa100000 ---p 00000000 00:00 0 
26dafa100000-26dafa103000 rw-p 00000000 00:00 0 
26dafa103000-26dafa104000 ---p 00000000 00:00 0 
26dafa104000-26dafa17f000 rwxp 00000000 00:00 0 
26dafa17f000-26dafa180000 ---p 00000000 00:00 0 
26dafa180000-26dafa183000 rw-p 00000000 00:00 0 
26dafa183000-26dafa184000 ---p 00000000 00:00 0 
26dafa184000-26dafa1ff000 rwxp 00000000 00:00 0 
26dafa1ff000-26dafa200000 ---p 00000000 00:00 0 
26dafa200000-26dafa203000 rw-p 00000000 00:00 0 
26dafa203000-26dafa204000 ---p 00000000 00:00 0 
26dafa204000-26dafa27f000 rwxp 00000000 00:00 0 
26dafa27f000-26db19ead000 ---p 00000000 00:00 0 
2adf28e80000-2adf28f00000 rw-p 00000000 00:00 0 
2b4467900000-2b4467980000 rw-p 00000000 00:00 0 
2bb8adb80000-2bb8adc00000 rw-p 00000000 00:00 0 
2dadb8480000-2dadb8500000 rw-p 00000000 00:00 0 
2fa869080000-2fa869100000 rw-p 00000000 00:00 0 
325d21200000-325d21280000 rw-p 00000000 00:00 0 
3462c4b00000-3462c4b80000 rw-p 00000000 00:00 0 
34a98af80000-34a98b000000 rw-p 00000000 00:00 0 
34efe4300000-34efe4380000 rw-p 00000000 00:00 0 
355999380000-355999400000 rw-p 00000000 00:00 0 
35c8d9680000-35c8d9685000 rw-p 00000000 00:00 0 
36fd03c00000-36fd03c80000 rw-p 00000000 00:00 0 
371ab4200000-371ab4280000 rw-p 00000000 00:00 0 
37e430000000-37e430080000 rw-p 00000000 00:00 0 
37f3b2f00000-37f3b2f80000 rw-p 00000000 00:00 0 
389966a80000-389966b8a000 rw-p 00000000 00:00 0 
3ad500400000-3ad500480000 rw-p 00000000 00:00 0 
3aff91d80000-3aff91de2000 rw-p 00000000 00:00 0 
3b2f0d680000-3b2f0d700000 rw-p 00000000 00:00 0 
3fba22080000-3fba22100000 rw-p 00000000 00:00 0 
7fb4bfffc000-7fb4c3ffd000 rw-s 00000000 00:1a 116                        /dev/shm/pulse-shm-3506809168
7fb4c3ffd000-7fb4c7ffe000 rw-s 00000000 00:1a 115                        /dev/shm/pulse-shm-136900218
7fb4c7ffe000-7fb4cbfff000 rw-s 00000000 00:1a 95                         /dev/shm/pulse-shm-1835135660
7fb4cbfff000-7fb4d0000000 rw-s 00000000 00:1a 93                         /dev/shm/pulse-shm-465478744
7fb4d0000000-7fb4d0029000 rw-p 00000000 00:00 0 
7fb4d0029000-7fb4d4000000 ---p 00000000 00:00 0 
7fb4d615e000-7fb4d615f000 ---p 00000000 00:00 0 
7fb4d615f000-7fb4d695f000 rw-p 00000000 00:00 0 
7fb4d695f000-7fb4d6960000 ---p 00000000 00:00 0 
7fb4d6960000-7fb4d7160000 rw-p 00000000 00:00 0 
7fb4d7160000-7fb4d7180000 rw-s 00000000 00:1a 195                        /dev/shm/.org.chromium.Chromium.5U4VoF (deleted)
7fb4d7180000-7fb4d71c0000 rw-s 00000000 00:1a 194                        /dev/shm/.org.chromium.Chromium.RLeLh9 (deleted)
7fb4d71c0000-7fb4d71e0000 rw-s 00000000 00:1a 185                        /dev/shm/.org.chromium.Chromium.vuEDaD (deleted)
7fb4d71e0000-7fb4d7220000 rw-s 00000000 00:1a 124                        /dev/shm/.org.chromium.Chromium.QXky36 (deleted)
7fb4d7260000-7fb4d72a0000 rw-s 00000000 00:1a 190                        /dev/shm/.org.chromium.Chromium.iNwIs3 (deleted)
7fb4d72a0000-7fb4d72e0000 rw-s 00000000 00:1a 189                        /dev/shm/.org.chromium.Chromium.TCc7Dx (deleted)
7fb4d7320000-7fb4d7340000 rw-s 00000000 00:1a 153                        /dev/shm/.org.chromium.Chromium.niC6By (deleted)
7fb4d7340000-7fb4d7380000 rw-s 00000000 00:1a 184                        /dev/shm/.org.chromium.Chromium.Bckk6z (deleted)
7fb4d7380000-7fb4d73c0000 rw-s 00000000 00:1a 183                        /dev/shm/.org.chromium.Chromium.cjU5H8 (deleted)
7fb4d73c0000-7fb4d7400000 rw-s 00000000 00:1a 182                        /dev/shm/.org.chromium.Chromium.T0uSjH (deleted)
7fb4d7400000-7fb4d7440000 rw-s 00000000 00:1a 181                        /dev/shm/.org.chromium.Chromium.QW3FVf (deleted)
7fb4d7440000-7fb4d7480000 rw-s 00000000 00:1a 180                        /dev/shm/.org.chromium.Chromium.VUxuxO (deleted)
7fb4d74c0000-7fb4d7500000 rw-s 00000000 00:1a 178                        /dev/shm/.org.chromium.Chromium.HikaLV (deleted)
7fb4d7640000-7fb4d7680000 rw-s 00000000 00:1a 171                        /dev/shm/.org.chromium.Chromium.4UVv2P (deleted)
7fb4d7680000-7fb4d76c0000 rw-s 00000000 00:1a 170                        /dev/shm/.org.chromium.Chromium.BpeuEo (deleted)
7fb4d7700000-7fb4d7740000 rw-s 00000000 00:1a 168                        /dev/shm/.org.chromium.Chromium.vB2tSv (deleted)
7fb4d7780000-7fb4d77c0000 rw-s 00000000 00:1a 166                        /dev/shm/.org.chromium.Chromium.8lIy6C (deleted)
7fb4d7840000-7fb4d7880000 rw-s 00000000 00:1a 162                        /dev/shm/.org.chromium.Chromium.aN74AR (deleted)
7fb4d7880000-7fb4d78c0000 rw-s 00000000 00:1a 161                        /dev/shm/.org.chromium.Chromium.ExRifq (deleted)
7fb4d78c0000-7fb4d7900000 rw-s 00000000 00:1a 160                        /dev/shm/.org.chromium.Chromium.O1MxTY (deleted)
7fb4d7940000-7fb4d7980000 rw-s 00000000 00:1a 158                        /dev/shm/.org.chromium.Chromium.mxd5b6 (deleted)
7fb4d79c0000-7fb4d7a00000 rw-s 00000000 00:1a 156                        /dev/shm/.org.chromium.Chromium.byaHud (deleted)
7fb4d7a40000-7fb4d7a80000 rw-s 00000000 00:1a 132                        /dev/shm/.org.chromium.Chromium.2FEnNk (deleted)
7fb4d7ac0000-7fb4d7b00000 rw-s 00000000 00:1a 130                        /dev/shm/.org.chromium.Chromium.HFba6r (deleted)
7fb4d7b00000-7fb4d7b40000 rw-s 00000000 00:1a 129                        /dev/shm/.org.chromium.Chromium.tFrAK0 (deleted)
7fb4d7b40000-7fb4d7b80000 rw-s 00000000 00:1a 152                        /dev/shm/.org.chromium.Chromium.4rXuc5 (deleted)
7fb4d7b80000-7fb4d7bc0000 rw-s 00000000 00:1a 151                        /dev/shm/.org.chromium.Chromium.ei9cxE (deleted)
7fb4d7f40000-7fb4d7f80000 rw-s 00000000 00:1a 146                        /dev/shm/.org.chromium.Chromium.hbGEFc (deleted)
7fb4d7fc0000-7fb4d8000000 rw-s 00000000 00:1a 144                        /dev/shm/.org.chromium.Chromium.TaWipl (deleted)
7fb4d8000000-7fb4d803c000 rw-p 00000000 00:00 0 
7fb4d803c000-7fb4dc000000 ---p 00000000 00:00 0 
7fb4dc000000-7fb4dc021000 rw-p 00000000 00:00 0 
7fb4dc021000-7fb4e0000000 ---p 00000000 00:00 0 
7fb4e0000000-7fb4e0022000 rw-p 00000000 00:00 0 
7fb4e0022000-7fb4e4000000 ---p 00000000 00:00 0 
7fb4e4030000-7fb4e4094000 rw-s 00000000 00:1a 111                        /dev/shm/.org.chromium.Chromium.7I5ZtW (deleted)
7fb4e4094000-7fb4e40f4000 rw-s 00000000 00:1a 100                        /dev/shm/.org.chromium.Chromium.L6QAhS (deleted)
7fb4e40f4000-7fb4e4154000 rw-s 00000000 00:1a 91                         /dev/shm/.org.chromium.Chromium.Sf8WzY (deleted)
7fb4e4154000-7fb4e4155000 ---p 00000000 00:00 0 
7fb4e4155000-7fb4e4955000 rw-p 00000000 00:00 0 
7fb4e4995000-7fb4e49d5000 rw-s 00000000 00:1a 137                        /dev/shm/.org.chromium.Chromium.Hx0IZk (deleted)
7fb4e49d5000-7fb4e637d000 r-xp 00000000 08:01 26878205                   /usr/lib/x86_64-linux-gnu/libicudata.so.60.2
7fb4e637d000-7fb4e657c000 ---p 019a8000 08:01 26878205                   /usr/lib/x86_64-linux-gnu/libicudata.so.60.2
7fb4e657c000-7fb4e657d000 r--p 019a7000 08:01 26878205                   /usr/lib/x86_64-linux-gnu/libicudata.so.60.2
7fb4e657d000-7fb4e657e000 rw-p 019a8000 08:01 26878205                   /usr/lib/x86_64-linux-gnu/libicudata.so.60.2
7fb4e657e000-7fb4e6721000 r-xp 00000000 08:01 26878215                   /usr/lib/x86_64-linux-gnu/libicuuc.so.60.2
7fb4e6721000-7fb4e6920000 ---p 001a3000 08:01 26878215                   /usr/lib/x86_64-linux-gnu/libicuuc.so.60.2
7fb4e6920000-7fb4e6933000 r--p 001a2000 08:01 26878215                   /usr/lib/x86_64-linux-gnu/libicuuc.so.60.2
7fb4e6933000-7fb4e6934000 rw-p 001b5000 08:01 26878215                   /usr/lib/x86_64-linux-gnu/libicuuc.so.60.2
7fb4e6934000-7fb4e6935000 rw-p 00000000 00:00 0 
7fb4e6935000-7fb4e6bc7000 r-xp 00000000 08:01 26878207                   /usr/lib/x86_64-linux-gnu/libicui18n.so.60.2
7fb4e6bc7000-7fb4e6dc6000 ---p 00292000 08:01 26878207                   /usr/lib/x86_64-linux-gnu/libicui18n.so.60.2
7fb4e6dc6000-7fb4e6dd5000 r--p 00291000 08:01 26878207                   /usr/lib/x86_64-linux-gnu/libicui18n.so.60.2
7fb4e6dd5000-7fb4e6dd6000 rw-p 002a0000 08:01 26878207                   /usr/lib/x86_64-linux-gnu/libicui18n.so.60.2
7fb4e6dd6000-7fb4e6e1b000 r-xp 00000000 08:01 27136130                   /usr/lib/x86_64-linux-gnu/libunity/libunity-protocol-private.so.0.0.0
7fb4e6e1b000-7fb4e701a000 ---p 00045000 08:01 27136130                   /usr/lib/x86_64-linux-gnu/libunity/libunity-protocol-private.so.0.0.0
7fb4e701a000-7fb4e701d000 r--p 00044000 08:01 27136130                   /usr/lib/x86_64-linux-gnu/libunity/libunity-protocol-private.so.0.0.0
7fb4e701d000-7fb4e701e000 rw-p 00047000 08:01 27136130                   /usr/lib/x86_64-linux-gnu/libunity/libunity-protocol-private.so.0.0.0
7fb4e701e000-7fb4e7057000 r-xp 00000000 08:01 26877853                   /usr/lib/x86_64-linux-gnu/libdee-1.0.so.4.2.1
7fb4e7057000-7fb4e7257000 ---p 00039000 08:01 26877853                   /usr/lib/x86_64-linux-gnu/libdee-1.0.so.4.2.1
7fb4e7257000-7fb4e7258000 r--p 00039000 08:01 26877853                   /usr/lib/x86_64-linux-gnu/libdee-1.0.so.4.2.1
7fb4e7258000-7fb4e7259000 rw-p 0003a000 08:01 26877853                   /usr/lib/x86_64-linux-gnu/libdee-1.0.so.4.2.1
7fb4e7259000-7fb4e72f6000 r-xp 00000000 08:01 26878675                   /usr/lib/x86_64-linux-gnu/libunity.so.9.0.2
7fb4e72f6000-7fb4e74f6000 ---p 0009d000 08:01 26878675                   /usr/lib/x86_64-linux-gnu/libunity.so.9.0.2
7fb4e74f6000-7fb4e74fa000 r--p 0009d000 08:01 26878675                   /usr/lib/x86_64-linux-gnu/libunity.so.9.0.2
7fb4e74fa000-7fb4e74fc000 rw-p 000a1000 08:01 26878675                   /usr/lib/x86_64-linux-gnu/libunity.so.9.0.2
7fb4e74fc000-7fb4e74fd000 rw-p 00000000 00:00 0 
7fb4e74fd000-7fb4e74fe000 ---p 00000000 00:00 0 
7fb4e74fe000-7fb4e7cfe000 rw-p 00000000 00:00 0 
7fb4e7cfe000-7fb4e7dc3000 r-xp 00000000 07:15 15069                      /snap/skype/51/usr/share/skypeforlinux/resources/app.asar.unpacked/node_modules/electron-ssid/build/Release/electron-ssid.node
7fb4e7dc3000-7fb4e7fc2000 ---p 000c5000 07:15 15069                      /snap/skype/51/usr/share/skypeforlinux/resources/app.asar.unpacked/node_modules/electron-ssid/build/Release/electron-ssid.node
7fb4e7fc2000-7fb4e7fcb000 rw-p 000c4000 07:15 15069                      /snap/skype/51/usr/share/skypeforlinux/resources/app.asar.unpacked/node_modules/electron-ssid/build/Release/electron-ssid.node
7fb4e7fcb000-7fb4e7fdf000 rw-p 00000000 00:00 0 
7fb4e7fdf000-7fb4e7fff000 rw-p 00101000 07:15 15069                      /snap/skype/51/usr/share/skypeforlinux/resources/app.asar.unpacked/node_modules/electron-ssid/build/Release/electron-ssid.node
7fb4e7fff000-7fb4ec000000 rw-s 00000000 00:1a 12                         /dev/shm/pulse-shm-2958556533
7fb4ec000000-7fb4ec021000 rw-p 00000000 00:00 0 
7fb4ec021000-7fb4f0000000 ---p 00000000 00:00 0 
7fb4f002d000-7fb4f0091000 rw-s 00000000 00:1a 90                         /dev/shm/.org.chromium.Chromium.JPBrMl (deleted)
7fb4f0091000-7fb4f00d1000 rw-s 00000000 00:1a 134                        /dev/shm/.org.chromium.Chromium.ctJK62 (deleted)
7fb4f00f1000-7fb4f0151000 rw-s 00000000 00:1a 89                         /dev/shm/.org.chromium.Chromium.kfsXYI (deleted)
7fb4f0151000-7fb4f01d2000 rw-s 00000000 08:01 1838001                    /home/input0/snap/skype/common/.config/skypeforlinux/Cache/index
7fb4f01d2000-7fb4f01d3000 ---p 00000000 00:00 0 
7fb4f01d3000-7fb4f09d3000 rw-p 00000000 00:00 0 
7fb4f09d3000-7fb4f0a1f000 r-xp 00000000 07:15 484                        /snap/skype/51/usr/lib/x86_64-linux-gnu/libsecret-1.so.0.0.0
7fb4f0a1f000-7fb4f0c1e000 ---p 0004c000 07:15 484                        /snap/skype/51/usr/lib/x86_64-linux-gnu/libsecret-1.so.0.0.0
7fb4f0c1e000-7fb4f0c21000 r--p 0004b000 07:15 484                        /snap/skype/51/usr/lib/x86_64-linux-gnu/libsecret-1.so.0.0.0
7fb4f0c21000-7fb4f0c22000 rw-p 0004e000 07:15 484                        /snap/skype/51/usr/lib/x86_64-linux-gnu/libsecret-1.so.0.0.0
7fb4f0c22000-7fb4f0c26000 rw-p 00050000 07:15 484                        /snap/skype/51/usr/lib/x86_64-linux-gnu/libsecret-1.so.0.0.0
7fb4f0c26000-7fb4f0cba000 r-xp 00000000 07:15 15077                      /snap/skype/51/usr/share/skypeforlinux/resources/app.asar.unpacked/node_modules/keytar/build/Release/keytar.node
7fb4f0cba000-7fb4f0eb9000 ---p 00094000 07:15 15077                      /snap/skype/51/usr/share/skypeforlinux/resources/app.asar.unpacked/node_modules/keytar/build/Release/keytar.node
7fb4f0eb9000-7fb4f0ec0000 rw-p 00093000 07:15 15077                      /snap/skype/51/usr/share/skypeforlinux/resources/app.asar.unpacked/node_modules/keytar/build/Release/keytar.node
7fb4f0ec0000-7fb4f0ed3000 rw-p 00000000 00:00 0 
7fb4f0ed3000-7fb4f0eea000 rw-p 000c1000 07:15 15077                      /snap/skype/51/usr/share/skypeforlinux/resources/app.asar.unpacked/node_modules/keytar/build/Release/keytar.node
7fb4f0eea000-7fb4f12eb000 rw-s 00000000 00:1a 112                        /dev/shm/.org.chromium.Chromium.8b0GDI (deleted)
7fb4f12eb000-7fb4f132b000 rw-s 00000000 00:1a 110                        /dev/shm/.org.chromium.Chromium.wo010t (deleted)
7fb4f136b000-7fb4f13ab000 rw-s 00000000 00:1a 108                        /dev/shm/.org.chromium.Chromium.4MWzbK (deleted)
7fb4f13ab000-7fb4f13eb000 rw-s 00000000 00:1a 107                        /dev/shm/.org.chromium.Chromium.PCNSgn (deleted)
7fb4f13eb000-7fb4f142b000 rw-s 00000000 00:1a 106                        /dev/shm/.org.chromium.Chromium.UUZcm0 (deleted)
7fb4f146b000-7fb4f14ab000 rw-s 00000000 00:1a 104                        /dev/shm/.org.chromium.Chromium.MzjVwg (deleted)
7fb4f14bb000-7fb4f14cb000 rw-s 00000000 00:1a 118                        /dev/shm/.org.chromium.Chromium.GgMWqU (deleted)
7fb4f14cb000-7fb4f14eb000 rw-s 00000000 00:1a 109                        /dev/shm/.org.chromium.Chromium.CbpRGw (deleted)
7fb4f14eb000-7fb4f152b000 rw-s 00000000 00:1a 38                         /dev/shm/.org.chromium.Chromium.keWIHw (deleted)
7fb4f152b000-7fb4f156b000 rw-s 00000000 00:1a 102                        /dev/shm/.org.chromium.Chromium.9HJ9M9 (deleted)
7fb4f1577000-7fb4f1587000 rw-s 00000000 00:1a 113                        /dev/shm/.org.chromium.Chromium.UPK1Ee (deleted)
7fb4f1587000-7fb4f15eb000 rw-s 00000000 00:1a 34                         /dev/shm/.org.chromium.Chromium.leYub6 (deleted)
7fb4f15eb000-7fb4f162b000 rw-s 00000000 00:1a 97                         /dev/shm/.org.chromium.Chromium.6IeB32 (deleted)
7fb4f162b000-7fb4f1a2c000 rw-s 00000000 00:1a 85                         /dev/shm/.org.chromium.Chromium.6d3WFD (deleted)
7fb4f1a2c000-7fb4f1a6c000 rw-s 00000000 00:1a 83                         /dev/shm/.org.chromium.Chromium.IjR5gj (deleted)
7fb4f1a6c000-7fb4f1aac000 rw-s 00000000 00:1a 88                         /dev/shm/.org.chromium.Chromium.cG4AwK (deleted)
7fb4f1aac000-7fb4f1aec000 rw-s 00000000 00:1a 77                         /dev/shm/.org.chromium.Chromium.StnttE (deleted)
7fb4f1aec000-7fb4f1b2c000 rw-s 00000000 00:1a 71                         /dev/shm/.org.chromium.Chromium.xRFG4j (deleted)
7fb4f1b2c000-7fb4f1b2d000 ---p 00000000 00:00 0 
7fb4f1b2d000-7fb4f25f5000 rw-p 00000000 00:00 0 
7fb4f25f5000-7fb4f25f6000 ---p 00000000 00:00 0 
7fb4f25f6000-7fb4f2df6000 rw-p 00000000 00:00 0 
7fb4f2df6000-7fb4f2dfb000 r-xp 00000000 07:0b 2287                       /snap/core/5328/lib/x86_64-linux-gnu/libnss_dns-2.23.so
7fb4f2dfb000-7fb4f2ffb000 ---p 00005000 07:0b 2287                       /snap/core/5328/lib/x86_64-linux-gnu/libnss_dns-2.23.so
7fb4f2ffb000-7fb4f2ffc000 r--p 00005000 07:0b 2287                       /snap/core/5328/lib/x86_64-linux-gnu/libnss_dns-2.23.so
7fb4f2ffc000-7fb4f2ffd000 rw-p 00006000 07:0b 2287                       /snap/core/5328/lib/x86_64-linux-gnu/libnss_dns-2.23.so
7fb4f2ffd000-7fb4f2ffe000 ---p 00000000 00:00 0 
7fb4f2ffe000-7fb4f37fe000 rw-p 00000000 00:00 0 
7fb4f37fe000-7fb4f37ff000 ---p 00000000 00:00 0 
7fb4f37ff000-7fb4f3fff000 rw-p 00000000 00:00 0 
7fb4f3fff000-7fb4f8000000 rw-s 00000000 00:1a 7                          /dev/shm/pulse-shm-796608596
7fb4f8000000-7fb4f8083000 rw-p 00000000 00:00 0 
7fb4f8083000-7fb4fc000000 ---p 00000000 00:00 0 
7fb4fc000000-7fb4fc021000 rw-p 00000000 00:00 0 
7fb4fc021000-7fb500000000 ---p 00000000 00:00 0 
7fb500000000-7fb500021000 rw-p 00000000 00:00 0 
7fb500021000-7fb504000000 ---p 00000000 00:00 0 
7fb504000000-7fb504021000 rw-p 00000000 00:00 0 
7fb504021000-7fb508000000 ---p 00000000 00:00 0 
7fb508000000-7fb508021000 rw-p 00000000 00:00 0 
7fb508021000-7fb50c000000 ---p 00000000 00:00 0 
7fb50c000000-7fb50c30a000 rw-p 00000000 00:00 0 
7fb50c30a000-7fb510000000 ---p 00000000 00:00 0 
7fb510000000-7fb510028000 rw-p 00000000 00:00 0 
7fb510028000-7fb514000000 ---p 00000000 00:00 0 
7fb514000000-7fb514008000 rw-s 00000000 00:1a 187                        /dev/shm/.org.chromium.Chromium.wp000v (deleted)
7fb514008000-7fb514048000 rw-s 00000000 00:1a 68                         /dev/shm/.org.chromium.Chromium.kV2UFZ (deleted)
7fb514048000-7fb514088000 rw-s 00000000 00:1a 87                         /dev/shm/.org.chromium.Chromium.JUxFl8 (deleted)
7fb514088000-7fb5140c8000 rw-s 00000000 00:1a 65                         /dev/shm/.org.chromium.Chromium.476qSk (deleted)
7fb5140c8000-7fb514108000 rw-s 00000000 00:1a 96                         /dev/shm/.org.chromium.Chromium.1d878F (deleted)
7fb514108000-7fb514148000 rw-s 00000000 00:1a 86                         /dev/shm/.org.chromium.Chromium.IHmLaw (deleted)
7fb514148000-7fb51414a000 r-xp 00000000 08:01 8917743                    /lib/x86_64-linux-gnu/libnss_mdns4_minimal.so.2
7fb51414a000-7fb514349000 ---p 00002000 08:01 8917743                    /lib/x86_64-linux-gnu/libnss_mdns4_mini
$

Cool, so when i read the backtrace, I understood that, this might be a memory corruption in `malloc()`.

So basically, the memory allocator allocates pages of memory at once for use of programs, and it gives you a pointer within them. Since this files which i am trying to share may be larger for skype to handle during the call (PS: I was just sharing an jpg file in this case which was of 800kB). But for skype if a larger program is allocating larger amounts of memory and writing further past the end of your allocated space, then you'll end up attempting to write into unallocated memory and may cause a memory corruption.



Being a fan of responsible disclosure, I submitted this to Microsoft on 8 August 2018, but  MS says "Upon investigation, we have determined that this submission does not meet the bar for security servicing"  🤦

Okay, but I passed on this message to skype team on twitter, and they looked into this!
At last, this was patched on Skype version 8.29.0.41 on Linux.


Regards

Thursday, 9 August 2018

A bug that affects million users - Kaspersky VPN

Hi Internet,

Summary:
The issue exists in Kaspersky VPN <=v1.4.0.216  which leaks your DNS Address even after you're connected to any virtual server. (Tested on Android 8.1.0)

What is a DNS leaks ?
In this context, with "DNS leak" it means an unencrypted DNS query sent by your system OUTSIDE the established VPN tunnel.

Kaspersky VPN is one of the most trusted VPN which comes with 1,000,000+ tier downloads in android market, however it was observed that when it connects to any random virtual server still leaks your actual DNS address, this issue was reported too Kaspersky via Hackerone.

Steps to reproduce:
1. Visit IPleak (Note your actual DNS address).
2. Now, connect to any random virtual server using Kaspersky VPN.
3. Once you are successfully connected, navigate to IPleak you will observe that the DNS address still remains the same.

I believe this leaks the trace's of an end user, who wants to remain anonymous on the internet. I reported this vulnerability on Apr 21st (4 months ago) via H1, and a fix was pushed for same but no bounty was awarded.

“Kaspersky Lab would like to thank Dhiraj Mishra for discovering a vulnerability in the Android-based Kaspersky Secure Connection app, which allowed a DNS service to log the domain names of the sites visited by users. This vulnerability was responsibly reported by the researcher, and was fixed in June.

The Kaspersky Secure Connection app is currently out of the scope of the company’s Bug Bounty Program, so we could not reward Dhiraj under the current rules. We highly appreciate his work, and in the future the program may include new products. As stated in Kaspersky Lab’s Bug Bounty Program rules, bounties are currently paid for two major products: Kaspersky Internet Security and Kaspersky Endpoint Security. The company is ready to pay up to $20,000 for the discovery of some bugs in these products, and up to $100,000 for the most severe."

However, this was featured on TheRegister and BleepingComputer.



Regards
Dhiraj 

Thursday, 26 July 2018

misuse of realpath function on POSIX platforms - CVE-2018-14338

Hi Internet,

Product Affected:  Exiv2, a C++ library and a command line utility to read and write Exif, IPTC and XMP image metadata.

Summary:  samples/geotag.cpp in the example code of Exiv2 0.26 misuses the realpath function on POSIX platforms (other than Apple platforms) where glibc is not used, possibly leading to a buffer overflow.

Example:
However their are multiple files in /samples/ which are responsible for their own tests.
conntest.cpp = This file is used when a user needs to test http/https/ftp/ssh/sftp vased connection via exiv2

Similarly I had a look on geotag.cpp file which is responsible for  reading gpx files and update images with GPS tags.
While this file used `realpath()` however realpath function is broken by design - POSIX.1-2001
According to the documentation of `realpath()`  the output buffer needs to be at least of size `PATH_MAX` specifying output buffers large enough to handle the maximum-size possible result from path manipulation functions.

But in geotag.cpp the buffer size was not equal to PATH_MAX nor set to NULL
#ifdef __APPLE__
                    char   buffer[1024];
#else
                    char*  buffer = NULL;
#endif
                    char*  path = realpath(arg,buffer);
                    if  ( t && path ) {
                        if ( options.verbose) printf("%s %ld %s",path,(long int)t,asctime(localtime(&t)));
                        gFiles.push_back(path);
                    }
                    if ( path && path != buffer ) ::free((void*) path);
                }
                if ( type == typeUnknown ) {
                    fprintf(stderr,"error: illegal syntax %s\n",arg);
                    result = resultSyntaxError ;
                }
            } break;
        }
}
However, in that instance, buffer  size comes from `uv__fs_pathmax_size()`. That function attempts to use `pathconf(path, _PC_PATH_MAX)` as noted in the realpath(3) docs. But over here(geotag.cpp) `uv__fs_pathmax_size()` nor `pathconf(path, _PC_PATH_MAX)` is in use.

Passing an inadequately-sized output buffer to a path manipulation function can result in a buffer overflow. Such functions include `realpath()` `readlink()` `PathAppend()` and others.

A issue was submitted to exiv2 team and a commit was pushed to patch this issue, to fix this they called `pathconf()` for linux, or they could have simply set `PATH_MAX+1` to resolve this.
diff --git a/samples/geotag.cpp b/samples/geotag.cpp
index 1355827..4da38af 100644
--- a/samples/geotag.cpp
+++ b/samples/geotag.cpp
@@ -806,8 +806,11 @@ int main(int argc,const char* argv[])
                 if ( options.verbose ) printf("%s %s ",arg,types[type]) ;
                 if ( type == typeImage ) {
                     time_t t    = readImageTime(std::string(arg)) ;
-#ifdef __APPLE__
+#if   defined(__APPLE__)
                     char   buffer[1024];
+#elif defined(__gnu_linux__)
+                    char   buffer[_MAX_PATH];
+                    pathconf(arg ,_MAX_PATH);
 #else
                     char*  buffer = NULL;
 #endif
CVE-2018-14338 was assign to this issue, Hope you like the read.
 
Regards
Dhiraj

Thursday, 19 July 2018

race condition in htslib - CVE-2018-14329

Hi Internet,

Product affected: htslib, a C library for high-throughput sequencing data format.

Summary: In HTSlib 1.8, a race condition in `cram/cram_io.c` might allow local users to overwrite arbitrary files via a symlink attack.

File faidx.c
       snprintf(fai_file, PATH_MAX, "%s.fai", fn);
        if (access(fai_file, R_OK) != 0)
            if (fai_build(fn) != 0)
                return NULL;
}
The API for the fai_build* functions is to take a filename. This inherently leaves a race. Code currently does things like :
`if (!access(...)) fai_build()`
or
`if (!open(...)) fai_build()`

Both of these suffer the same problem - an attacker could symlink the file between the access/open check and the decision to rebuild it. This solution makes the build function itself unlink the file and does an exclusive open so it'll fail if someone wins the race between unlink and hopen. There is one small fly in the ointment - we can currently do "samtools faidx s3:foo.fa" and this will open s3:foo.fa.fai. The unlink will fail, so we've now changed behaviour because previously we could overwrite an existing s3 fai file with a new one whereas now we require the user to manually delete their existing one first. Without having an `hunlink()` function we're scuppered on this.
@@ -493,7 +493,12 @@ static int fai_build3_core(const char *fn, const char *fnfai, const char *fngzi)
         goto fail;
     }
 
-    fp = hopen(fnfai, "wb");
+    if (hisremote(fnfai)) {
+        fp = hopen(fnfai, "wb");
+    } else {
+        unlink(fnfai);
+        fp = hopen(fnfai, "wbx");
+    }
 
     if ( !fp ) {
         hts_log_error("Failed to open %s index %s : %s", file_type, fnfai, strerror(errno));
The only possible workaround over here is to validate the filename first, so if the fasta file is fd_backend we use exclusive open, and don't otherwise. This is what is implemented here and a patch was deployed, hope you like the read.

Exploiting: I 'assume' that this can be exploited by hardlink.
exploit.c
#include 
int main()
{
  if (geteuid()!=0) exit(1);
  setuid(geteuid());
  char *args[] = { "/bin/sh", 0 };
  return execve(args[0], args, 0);
}
Trigger an race condition by creating a hardlink to the vulnerable program.
while :; do ln -f ./vulnpoc; ln -f ./exploit; done
Where, the htslib team says, probably this is not the way to exploit,  I hadn't really thought about the hardlink case, although again affecting those only applies to writeable / shared locations, so it's also high improbable to cause bugs either way. Hope you like the read.


Regards
Dhiraj

Friday, 13 July 2018

race condition in mstdlib - CVE-2018-14043

Hi Internet,

Affected Product: mstdlib is designed to provide features not normally found in libc but also to be used in place of libc.

Summary: mstdlib (aka the M Standard Library for C) 1.2.0 has incorrect file access control in situations where `M_fs_perms_can_access` attempts to delete an existing file (that lacks public read/write access) during a copy operation, related to `fs/m_fs.c and fs/m_fs_path.c`. An attacker could create the file and then would have access to the data.

Race Condition: A race condition occurs within concurrent environments, and is effectively a property of a code sequence. Depending on the context, a code sequence may be in the form of a function call, a small number of instructions, a series of program invocations, etc. [1]

Outcome: CVE-2018-14043 was assign to this and contributed to M Standard Library for C.

InProcess: I have requested to Internet Bug Bounty Program panel members to consider this for a bounty (fingerscrossed).

Well, this was tough to identify! The file `m_fs_perms_unx.c` on line number 277 use's `access()` to call.
if (access(norm_path, access_mode) == -1) {
If an attacker can change anything along the path between the call `access()` and the files actually used, attacker may exploit the race condition it is possible to make changes to a path between calling M_fs_perms_can_access and doing something with the path. However, this function is conforming to ISO/IEC 9945-1:1990 and the same security considerations apply when using `access()` directly.

As reported with a day quick commit was pushed in master branch.
@@ -101,6 +101,15 @@ static M_bool M_fs_isfileintodir(const char *p1, const char *p2, char **new_p2)
  return M_TRUE;
 }
 
+/* Used by copy and move to determine if we can write to the given path
+ * based on a file already existing there or not.
+ *
+ * access is used to determine existence because we don't want to overwrite
+ * if there already is a file. This is not guaranteed because if there is
+ * a race condition where a file is created after this check it will be
+ * overwritten. Not much we can do about that. It shouldn't pose a security
+ * issue since this is more of a request than a requirement.
+ */
 static M_bool M_fs_check_overwrite_allowed(const char *p1, const char *p2, M_uint32 mode)
 {
  M_fs_info_t  *info = NULL;
@@ -129,8 +138,7 @@ static M_bool M_fs_check_overwrite_allowed(const char *p1, const char *p2, M_uin
 
  if (type != M_FS_TYPE_DIR) {
   /* File exists at path. */
-  if (M_fs_perms_can_access(p2, M_FS_PERMS_MODE_NONE) == M_FS_ERROR_SUCCESS)
-  {
+  if (M_fs_perms_can_access(p2, M_FS_PERMS_MODE_NONE) == M_FS_ERROR_SUCCESS) {
    ret = M_FALSE;
    goto done;
   }
@@ -209,19 +217,6 @@ static M_fs_error_t M_fs_copy_file(const char *path_old, const char *path_new, M
  size_t         offset;
  M_fs_error_t   res;
 
- /* We're going to create/open/truncate the new file, then as we read the contents from the old file we'll write it
-   * to new file. */
- if (M_fs_perms_can_access(path_new, M_FS_PERMS_MODE_NONE) == M_FS_ERROR_SUCCESS) {
-  /* Try to delete the file since we'll be overwrite it. This is so when we create the file we create it without
-    * any permissions and to ensure that anything that has the file already open won't be able to read the new
-   * contents we're writing to the file or be able to change the perms. There is an unavoidable race condition
-   * between deleting and creating the file where someone could create the file and have access. However,
-   * depending on the OS they may have access even if the file is created with no perms... */
-  res = M_fs_delete(path_new, M_FALSE, NULL, M_FS_PROGRESS_NOEXTRA);
-  if (res != M_FS_ERROR_SUCCESS) {
-   return res;
-  }
- }
  /* Open the old file */
  res = M_fs_file_open(&fd_old, path_old, M_FS_BUF_SIZE, M_FS_FILE_MODE_READ|M_FS_FILE_MODE_NOCREATE, NULL);
  if (res != M_FS_ERROR_SUCCESS) {
@@ -236,6 +231,9 @@ static M_fs_error_t M_fs_copy_file(const char *path_old, const char *path_new, M
   }
   perms = M_fs_info_get_perms(info);
  }
+
+ /* We're going to create/open/truncate the new file, then as we read the contents from the old file we'll write it
+  * to new file. */
  res = M_fs_file_open(&fd_new, path_new, M_FS_BUF_SIZE, M_FS_FILE_MODE_WRITE|M_FS_FILE_MODE_OVERWRITE, perms);
  M_fs_info_destroy(info);
  if (res != M_FS_ERROR_SUCCESS) {
@@ -333,7 +331,7 @@ M_fs_error_t M_fs_move(const char *path_old, const char *path_new, M_uint32 mode
  }
 
  /* Normalize the old path and do basic checks that it exists. We'll leave really checking that the old path
-   * existing to rename because any check we perform may not be true when rename is called. */
+  * existing to rename because any check we perform may not be true when rename is called. */
  res = M_fs_path_norm(&norm_path_old, path_old, M_FS_PATH_NORM_RESALL, M_FS_SYSTEM_AUTO);
  if (res != M_FS_ERROR_SUCCESS) {
   M_free(norm_path_new);
@@ -351,7 +349,7 @@ M_fs_error_t M_fs_move(const char *path_old, const char *path_new, M_uint32 mode
   return res;
  }
 
-  /* There is a race condition where the path could not exist but be created between the exists check and calling
+ /* There is a race condition where the path could not exist but be created between the exists check and calling
   * rename to move the file but there isn't much we can do in this case. copy will delete and the file so this
   * situation won't cause an error. */
  if (!M_fs_check_overwrite_allowed(norm_path_old, norm_path_new, mode)) {
@@ -399,15 +397,15 @@ M_fs_error_t M_fs_move(const char *path_old, const char *path_new, M_uint32 mode
    res = M_fs_delete(norm_path_old, M_TRUE, NULL, M_FS_PROGRESS_NOEXTRA);
   } else {
    /* Failure - Delete the new files that were copied but only if we are not overwriting. We don't
-     * want to remove any existing files (especially if the dest is a dir). */
+    * want to remove any existing files (especially if the dest is a dir). */
    if (!(mode & M_FS_FILE_MODE_OVERWRITE)) {
     M_fs_delete(norm_path_new, M_TRUE, NULL, M_FS_PROGRESS_NOEXTRA);
    }
    res = M_FS_ERROR_GENERIC;
   }
  } else {
   /* Call the cb with the result of the move whether it was a success for fail. We call the cb only if the
-    * result of the move is not M_FS_ERROR_NOT_SAMEDEV because the copy operation will call the cb for us. */
+   * result of the move is not M_FS_ERROR_NOT_SAMEDEV because the copy operation will call the cb for us. */
   if (cb) {
    M_fs_progress_set_result(progress, res);
    if (!cb(progress)) {
@@ -465,7 +463,7 @@ M_fs_error_t M_fs_copy(const char *path_old, const char *path_new, M_uint32 mode
  }
 
  /* Normalize the old path and do basic checks that it exists. We'll leave really checking that the old path
-   * existing to rename because any check we perform may not be true when rename is called. */
+  * existing to rename because any check we perform may not be true when rename is called. */
  res = M_fs_path_norm(&norm_path_old, path_old, M_FS_PATH_NORM_RESALL, M_FS_SYSTEM_AUTO);
  if (res != M_FS_ERROR_SUCCESS) {
   M_free(norm_path_new);
@@ -485,7 +483,7 @@ M_fs_error_t M_fs_copy(const char *path_old, const char *path_new, M_uint32 mode
 
  type = M_fs_info_get_type(info);
 
-  /* There is a race condition where the path could not exist but be created between the exists check and calling
+ /* There is a race condition where the path could not exist but be created between the exists check and calling
   * rename to move the file but there isn't much we can do in this case. copy will delete and the file so this
   * situation won't cause an error. */
  if (!M_fs_check_overwrite_allowed(norm_path_old, norm_path_new, mode)) {
@@ -497,7 +495,7 @@ M_fs_error_t M_fs_copy(const char *path_old, const char *path_new, M_uint32 mode
 
  entries = M_fs_dir_entries_create();
  /* No need to destroy info  because it's now owned by entries and will be destroyed when entries is destroyed.
-   * M_FS_DIR_WALK_FILTER_READ_INFO_BASIC doesn't actually get the perms it's just there to ensure the info is
+  * M_FS_DIR_WALK_FILTER_READ_INFO_BASIC doesn't actually get the perms it's just there to ensure the info is
   * stored in the entry. */
  M_fs_dir_entries_insert(entries, M_fs_dir_walk_fill_entry(norm_path_new, NULL, type, info, M_FS_DIR_WALK_FILTER_READ_INFO_BASIC));
  if (type == M_FS_TYPE_DIR) {
@@ -523,7 +521,7 @@ M_fs_error_t M_fs_copy(const char *path_old, const char *path_new, M_uint32 mode
 
    type = M_fs_dir_entry_get_type(entry);
    /* The total isn't the total number of files but the total number of operations. 
-     * Making dirs and symlinks is one operation and copying a file will be split into
+    * Making dirs and symlinks is one operation and copying a file will be split into
     * multiple operations. Copying uses the M_FS_BUF_SIZE to read and write in
     * chunks. We determine how many chunks will be needed to read the entire file and
     * use that for the number of operations for the file. */
@@ -600,7 +598,7 @@ M_fs_error_t M_fs_copy(const char *path_old, const char *path_new, M_uint32 mode
  }
 
  /* Delete the file(s) if it could not be copied properly, but only if we are not overwriting.
-   * If we're overwriting then there could be other files in that location (especially if it's a dir). */
+  * If we're overwriting then there could be other files in that location (especially if it's a dir). */
  if (res != M_FS_ERROR_SUCCESS && !(mode & M_FS_FILE_MODE_OVERWRITE)) {
   M_fs_delete(path_new, M_TRUE, NULL, M_FS_PROGRESS_NOEXTRA);
  }
@@ -659,7 +657,7 @@ M_fs_error_t M_fs_delete(const char *path, M_bool remove_children, M_fs_progress
  entries = M_fs_dir_entries_create();
 
  /* Recursive directory deletion isn't intuitive. We have to generate a list of files and delete the list.
-   * We cannot delete as walk because not all file systems support that operation. The walk; delete; behavior
+  * We cannot delete as walk because not all file systems support that operation. The walk; delete; behavior
   * is undefined in Posix and HFS is known to skip files if the directory contents is modifies as the
   * directory is being walked. */
  if (type == M_FS_TYPE_DIR && remove_children) {
@@ -671,7 +669,7 @@ M_fs_error_t M_fs_delete(const char *path, M_bool remove_children, M_fs_progress
  }
 
  /* Add the original path to the list of entries. This may be the only entry in the list. We need to add
-   * it after a potential walk because we can't delete a directory that isn't empty.
+  * it after a potential walk because we can't delete a directory that isn't empty.
   * Note: 
   *   - The info will be owned by the entry and destroyed when it is destroyed. 
   *   - The basic info param doesn't get the info in this case. it's set so the info is stored in the entry. */
@@ -680,7 +678,7 @@ M_fs_error_t M_fs_delete(const char *path, M_bool remove_children, M_fs_progress
  len = M_fs_dir_entries_len(entries);
  if (cb) {
   /* Create the progress. The same progress will be used for the entire operation. It will be updated with
-    * new info as necessary. */
+   * new info as necessary. */
   progress = M_fs_progress_create();
 
   /* Get the total size of all files to be deleted if using the progress cb and size totals is set. */
PS: Don't try to delete the file when copying. It could cause a security issue if the file exists and doesn't allow other's to read/write, delete could allow someone to create the file and have access to the data.

I am still working on, how to weaponize this bug (I know most of my post say's this but, I am working on all those). Anyways, hope you like the read.

It was not a comprehensive review but addresses the concerns of this ticket. - said by member of mstdlib. 


Regards
Dhiraj

Wednesday, 11 July 2018

strncat() without bounds - Samsung TizenRT

Hi Internet,

Product affected: Samsung TizenRT is a lightweight RTOS-based platform to support low-end IoT devices

Summary: File external/webserver/http_client.c, `strncat()` was being used without calculating the remaining length of the destination string buffer in this case it might allow attackers to trigger a bufferoverflow via a long query that is processed by the `strcat` function.

I feel the risk is high because the length parameter appears to be a constant, instead of computing the number of characters left, anyways a quick patch was pushed for same.
#include 
@@ -593,8 +593,8 @@ void http_handle_file(struct http_client_t *client, int method, const char *url,
         } else
             valid = 1;
         /* Need to create file with unique file name */
-        strncat(path, url, HTTP_CONF_MAX_REQUEST_HEADER_URL_LENGTH);
-        strncat(path, "index.shtml", HTTP_CONF_MAX_REQUEST_HEADER_URL_LENGTH);
+        strncat(path, url, HTTP_CONF_MAX_REQUEST_HEADER_URL_LENGTH - strlen(path));
+        strncat(path, "index.shtml", HTTP_CONF_MAX_REQUEST_HEADER_URL_LENGTH - strlen(path));
         if (valid && (f = fopen(path, "w"))) {
             if (fputs(entity, f) < 0) {
                 HTTP_LOGE("Error: Fail to execute fputs\n");
@@ -619,7 +619,7 @@ void http_handle_file(struct http_client_t *client, int method, const char *url,
             HTTP_LOGE("ERROR: URL length is too long. Cannot send response\n");
         } else
             valid = 1;
-        if (valid && (f = fopen(strncat(path, url, HTTP_CONF_MAX_REQUEST_HEADER_URL_LENGTH), "w"))) {
+        if (valid && (f = fopen(strncat(path, url, HTTP_CONF_MAX_REQUEST_HEADER_URL_LENGTH - strlen(path)), "w"))) {
             if (fputs(entity, f) < 0) {
                 HTTP_LOGE("Error: Fail to execute fputs\n");
                 fclose(f);
@@ -643,7 +643,7 @@ void http_handle_file(struct http_client_t *client, int method, const char *url,
             HTTP_LOGE("ERROR: URL length is too long. Cannot send response\n");
         } else
             valid = 1;
-        if (valid && unlink(strncat(path, url, HTTP_CONF_MAX_REQUEST_HEADER_URL_LENGTH))) {
+        if (valid && unlink(strncat(path, url, HTTP_CONF_MAX_REQUEST_HEADER_URL_LENGTH - strlen(path)))) {
             HTTP_LOGE("fail to delete %s\n", url);
             if (http_send_response(client, 500, HTTP_ERROR_500, NULL) == HTTP_ERROR) {
                 HTTP_LOGE("Error: Fail to send response\n");
Now this prevent `bufferoverflow` by calculating the remaining length of the destination string buffer. Hope you like the read.


Regards
Dhiraj

Wednesday, 4 July 2018

strncat() without bounds - TOR

Hi Internet,


While going through the code of TOR it was observed that `backtrace.c` file which is located at `/src/lib/err/backtrace.c` at line number #L267-L268 was using `strncat()` which can be easily misused.
strncat(version, " ", sizeof(version)-1);
strncat(version, tor_version, sizeof(version)-1);
Example: Incorrectly computing the correct maximum size to add.

But, tor-security team marked this bug has low, because use of `strncat()` is a defence in depth mechanism that doesn't provide as much security as it should. Apart from that it cannot be influenceable by an attacker and they don't have control over this file and the version string.

Still a quick commit (patch) was push directly to the master branch of TOR
#include 
 #include 
 #include 
+#include 
 
 #ifdef HAVE_CYGWIN_SIGNAL_H
 #include 
@@ -264,16 +265,12 @@ dump_stack_symbols_to_error_fds(void)
 int
 configure_backtrace_handler(const char *tor_version)
 {
-  char version[128];
-  strncpy(version, "Tor", sizeof(version)-1);
+  char version[128] = "Tor\0";
 
   if (tor_version) {
-    strncat(version, " ", sizeof(version)-1);
-    strncat(version, tor_version, sizeof(version)-1);
+    snprintf(version, sizeof(version), "Tor %s", tor_version);
   }
 
-  version[sizeof(version) - 1] = 0;
-
   return install_bt_handler(version);
 }
Perhaps the reason `strncat()` was used to avoid including stuff from lib/string, This was nothing such great but hope you like the read.

Regards
Dhiraj

Sunday, 24 June 2018

Insecure Permissions in GIMP - CVE-2018-12713

Hi Internet,

#ShortPost

Summary: GIMP through 2.10.2 makes g_get_tmp_dir calls to establish temporary filenames, which may result in a filename that already exists, as demonstrated by the gimp_write_and_read_file function in app/tests/test-xcf.c. This might be leveraged by attackers to overwrite files or read file content that was intended to be private.
Img Src: https://www.gimp.org/

While having a look on GIMP code I observed that,
File test-xcf.cat#L314  which was;
filename = g_build_filename (g_get_tmp_dir (), "gimp-test.xcf", NULL);
The function with 'getenv("TMP")';it returns untrustable input. This issue was reported to GNOME GIMP team and a patch was pushed.

   GimpImage           *image;
   GimpImage           *loaded_image;
   GimpPlugInProcedure *proc;
-  gchar               *filename;
+  gchar               *filename = NULL;
+  gint                 file_handle;
   GFile               *file;
 
   /* Create the image */
@@ -311,7 +312,9 @@ gimp_write_and_read_file (Gimp     *gimp,
                          use_gimp_2_8_features);
 
   /* Write to file */
-  filename = g_build_filename (g_get_tmp_dir (), "gimp-test.xcf", NULL);
+  file_handle = g_file_open_tmp ("gimp-test-XXXXXX.xcf", &filename, NULL);
+  g_assert (file_handle != -1);
+  close (file_handle);
   file = g_file_new_for_path (filename);
   g_free (filename);
Not sure this is really solving the issue reported, which is that `g_get_tmp_dir()` uses environment variables (yet as g_file_open_tmp() uses g_get_tmp_dir()…). But at least g_file_open_tmp() should create unique temporary files, which prevents overriding existing files (which is most likely the only real attack possible here, or at least the only one I can think of unless some weird vulnerabilities exist in glib) CVE-2018-12713 was assigned to this issue.


Regards
Dhiraj

Friday, 15 June 2018

bufferoverflow() in evolution - CVE-2018-12422

Hi Internet,

#ShortPost

Evolution is a personal information management application that provides integrated mail, calendaring and address book functionality.

While going through the source code of GNOME evolution we observed that,

`addressbook/backends/ldap/e-book-backend-ldap.c` in Evolution-Data-Server in GNOME Evolution through 3.29.2 might allow attackers to trigger a Buffer Overflow via a long query that is processed by the `strcat ` function, CVE-2018-12422 was assigned to this issue.

We reported this to GNOME Evolution team and a patch was pushed for same, below code for your reference.

		if (!strcmp (propname, "x-evolution-any-field")) {
			gint i;
			gint query_length;
			gchar *big_query;
			GString *big_query;
			gchar *match_str;
			if (one_star) {
				g_free (str);

			match_str = g_strdup_printf ("=*%s*)", str);

			query_length = 3; /* strlen ("(|") + strlen (")") */

			for (i = 0; i < G_N_ELEMENTS (prop_info); i++) {
				query_length += 1 /* strlen ("(") */ + strlen (prop_info[i].ldap_attr) + strlen (match_str);
			}

			big_query = g_malloc0 (query_length + 1);
			strcat (big_query, "(|");
			big_query = g_string_sized_new (G_N_ELEMENTS (prop_info) * 7);
			g_string_append (big_query, "(|");
			for (i = 0; i < G_N_ELEMENTS (prop_info); i++) {
				if ((prop_info[i].prop_type & PROP_TYPE_STRING) != 0 &&
				    !(prop_info[i].prop_type & PROP_WRITE_ONLY) &&
				     !(prop_info[i].prop_type & PROP_EVOLVE)) &&
				    (ldap_data->bl->priv->calEntrySupported ||
				     !(prop_info[i].prop_type & PROP_CALENTRY))) {
					strcat (big_query, "(");
					strcat (big_query, prop_info[i].ldap_attr);
					strcat (big_query, match_str);
					g_string_append (big_query, "(");
					g_string_append (big_query, prop_info[i].ldap_attr);
					g_string_append (big_query, match_str);
				}
			}
			strcat (big_query, ")");
			g_string_append (big_query, ")");

			ldap_data->list = g_list_prepend (ldap_data->list, big_query);
			ldap_data->list = g_list_prepend (ldap_data->list, g_string_free (big_query, FALSE));

			g_free (match_str);
		}

		if (!strcmp (propname, "x-evolution-any-field")) {
			gint i;
			gint query_length;
			gchar *big_query;
			GString *big_query;
			gchar *match_str;

			match_str = g_strdup ("=*)");

			query_length = 3; /* strlen ("(|") + strlen (")") */

			for (i = 0; i < G_N_ELEMENTS (prop_info); i++) {
				query_length += 1 /* strlen ("(") */ + strlen (prop_info[i].ldap_attr) + strlen (match_str);
			}

			big_query = g_malloc0 (query_length + 1);
			strcat (big_query, "(|");
			big_query = g_string_sized_new (G_N_ELEMENTS (prop_info) * 7);
			g_string_append (big_query, "(|");
			for (i = 0; i < G_N_ELEMENTS (prop_info); i++) {
				if (!(prop_info[i].prop_type & PROP_WRITE_ONLY) &&
				    (ldap_data->bl->priv->evolutionPersonSupported ||
				     !(prop_info[i].prop_type & PROP_EVOLVE)) &&
				    (ldap_data->bl->priv->calEntrySupported ||
				     !(prop_info[i].prop_type & PROP_CALENTRY))) {
					strcat (big_query, "(");
					strcat (big_query, prop_info[i].ldap_attr);
					strcat (big_query, match_str);
					g_string_append (big_query, "(");
					g_string_append (big_query, prop_info[i].ldap_attr);
					g_string_append (big_query, match_str);
				}
			}
			strcat (big_query, ")");
			g_string_append (big_query, ")");

			ldap_data->list = g_list_prepend (ldap_data->list, big_query);
			ldap_data->list = g_list_prepend (ldap_data->list, g_string_free (big_query, FALSE));

			g_free (match_str);
		}

Source : https://gitlab.gnome.org/GNOME/evolution-data-server/commit/34bad61738e2127736947ac50e0c7969cc944972?view=inline

Mention's:
A shoutout to Zubin and Hardik we work together to find security bugs, Hope you like the read.


Regards
Dhiraj