DLL Hack in Notepad++
-
can’t npp exe call a function to check scintillas signature again?
Yes it can. But if an attacker has access to
SciLexer.DLLwhy wouldn’t they just attacknotepad++.exe. There is never a case wherenotepad++.exeis from a privileged location and loadsSciLexer.DLLfrom a non-privileged location.I think we need to take a step back because this discussion doesn’t sound like it is specific to Notepad++ and Scintilla. There are programs every day that have to load DLLs and have to make sure they are valid.
-
Good point but isn’t the beauty of this hack that there is just one function call which needs to be passed through to get
the same privilege as the main process? If it is running unprivileged good but if user runs it as administrator …You are right - loading a dll is a security issue and there is no safe way if MS doesn’t provide a way to run a program
in an encapsulated and signed environment. Something like CI+ or the HDMI content protection. But for this special issue,
I don’t see how it could be solved otherwise.Maybe a blog worth reading
https://blogs.technet.microsoft.com/srd/2009/04/14/ms09-014-addressing-the-safari-carpet-bomb-vulnerability/and there is one other issue which might be interesting. If the dll gets verified before load, this breaks npp for all
that use a different scintilla dll at the moment. I’m thinking about @cmeriaux for example.Cheers
Claudia -
Jfi - need to stay up early - I’m off.
Cheers
Claudia -
just one function call which needs to be passed through to get the same privilege as the main process?
That would assume you bypassed the Windows OS and got into the process space of Notepad++, which by then you have other issues ;)
Maybe a blog worth reading…
Will look at it tomorrow when I have a bit more time.
The safest solution would just be link the SciLexer statically instead of loading it dynamically but I’m not saying this is the right solution
-
The safest solution would just be link the SciLexer statically instead of loading it dynamically but I’m not saying this is the right solution
Yes, you’re right. it’ll be in the roadmap. In the meantime, I will do the quick fix - checking the scilexer.dll before loading it.
-
This headline is misleading. The DLL exists for CIA assets to use the cover app while it’s executing other code under the hood. From my reading, it’s not meant to be used against the person using notepad++, it’s to let them use notepad++ without raising any red flags while the DLL does data collection in the background. Those apps listed are the cover apps that look normal, the DLL hijack is to make them malicious with the knowledge of the operator.
ref: https://www.reddit.com/r/sysadmin/comments/5y0iqa/notepad_users_cia_has_had_a_dll_hijack_for_your/
@dail @Claudia-Frank
I agree that once users’ PC are compromised, the certificate checking is meaningless.
However, it makes harder (more job) to hack by checking certificate.
Just like knowing the lock is useless for people who are willing to go into my house, I still shut the door and lock it every morning when I leave home.We are in a f**king corrupted world! Sigh
-
I’m trying to get my head around this. No, not the part about the vulnerability, I understand that; the part I don’t understand is why all of a sudden this is like some big revelation…
-
@Alan-Kilborn
Don’t know if I understand you correctly. I guess Don and dail are very well aware about
the issue but when such a hack gets public it needs to be addressed. Don’t know
if you ever where in the position to explain to your IT Security department that such a hack
can’t be avoided as long as the operating system doesn’t ensure a safe environment.
They simply ignore it - as long as you don’t provide “a” solution it is marked a vulnerable and
you don’t get the permission to use this software anymore.
Notepad++ is used in companies - at least in the ones that I was working for.Cheers
Claudia -
Ah, okay Claudia, I think you understood my question and I understand your response. Thank you. Over my long period of observation, Windows seems inherently unsecure, probably because it is backing its way into security rather than having it be a major part of the design criterion. Sad.
-
I think there is no sens in checking certificates or staff like that because project is open source and everybody could create their own version of npp.
P.S. If someone is paranoid then could simply check md5 hash of original files(dlls and so on) :D
-
Yes, well, in this case you’d have to check the MD5 on the SciLexer.dll that will be loaded, which is perhaps a different one than the one that you think will get loaded. :)
-
I think there is no sens in checking certificates or staff like that because project is open source and everybody could create their own version of npp.
Not if the private key is kept private ;-) (so it is open source with parts being not open)
NO ;-) I don’t want to start a new discussion whether this makes sense. :-)If someone is paranoid then could simply check md5 hash of original files(dlls and so on)
Nope, md5 is considered insecure.
But all in all you are correct and Don, dail etc… do also agree once users’ PC are compromised …
Cheers
Claudia -
@Claudia-Frank ,
SHA-2 (SHA-256) or SHA-3 could be checked as well, just to be certain everything is ok and sleep calmly at night ahhaha :D -
Exploit Notepad++ (SciTE) ;-)
-
I still don’t understand what makes this unique to Notepad++/SciTE/Scintilla. You could do the same thing to any dll file.
-
There is nothing unique here. I could do the same thing with any dll file. Just you were unlucky to turn up in Wikileaks. :)
-
Signatures are a problem for people who want to build NPP by themselves and modify it.
They can’t sign DLL by themselves so they will need to go into NPP code and also disable the signature check.
Given that the added security is very very minimal I don’t think that NPP should test the signature of SciLexer.DLL.
Once an attacker has access to the file system to replace DLLs, specifically to ‘Program Files’ which usually requires administrator privileges the system is doomed anyway. -
Collisions on linking with a static build of scilexer.lib:
1>SciLexer.lib(PlatWin.obj) : error LNK2005: “public: virtual __cdecl Window::~Window(void)” (??1Window@@UEAA@XZ) ist bereits in fileBrowser.obj definiert.
1>SciLexer.lib(UniConversion.obj) : error LNK2005: “unsigned int __cdecl UTF8Length(wchar_t const *,unsigned int)” (?UTF8Length@@YAIPEB_WI@Z) ist bereits in UniConversion.obj definiert.
1>SciLexer.lib(Style.obj) : error LNK2005: “public: __cdecl Style::Style(void)” (??0Style@@QEAA@XZ) ist bereits in Notepad_plus.obj definiert.
1>SciLexer.lib(Style.obj) : error LNK2005: “public: __cdecl Style::~Style(void)” (??1Style@@QEAA@XZ) ist bereits in FindReplaceDlg.obj definiert.See http://www.scintilla.org/ScintillaDoc.html#BuildingScintilla for builds with STATIC_BUILD.
-
From what I’ve read in the Vault7 release, DLL injection is a great way to insert malicious code into the memory space where a legit DLL resides.
I’m not terribly sure if this directly applies, but I found this post on StackOverflow on how to avoid DLL injection in Windows processes/applications:
http://stackoverflow.com/questions/869320/how-do-i-prevent-dll-injection
Honestly, I hadn’t heard of DLL injection prior to the Vault7 release, so the my comprehension of the matter is limited. I have to say that if I understand it correctly though, the concept is fascinating.
-
Is it possible to know if my scilexer.dll has been hijacked?
