I don't use GDB a lot. But when I do, I generally use the pwndb extension.
It's written for exploit development, but even for debugging a C program. It makes things a lot nicer.
I love pwndbg. I work at the level of writing syscalls often, and it's wonderful that pwndbg's disassembler pretty-prints the operands of syscalls write next to the actual instruction.
isset() is a great additional tool and has most of the same properties of empty(), except it deals explicitly with null. Most importantly it doesn't produce exceptions, errors, warnings or notices when keys are missing or you attempt to de-reference null.
isset($var) will return false if you have deliberately set $var === NULL
Otherwise more or less fine?
The whole OP here is a longwinded way of observing that several built-in PHP functions don't know anything about types. You can't use switch() as it's usually documented either, for example, because that ignores types too.
There are ways around all these things, of course. PHP that doesn't suck is kind of the norm these days. Just stay the hell away from Wordpress
How can WordPress be so prominent and have so much money behind it and still have such garbage code? Are there giant companies still running PHP 4 server farms that need it to continue to be coded to 2003 standards? Is it some government op to ensure a good deal of the sites on the web are easily-hackable? Someone explain this to me.
This should be a lesson for everyone. Code quality doesn't matter, language doesn't matter, it only matters if people want your product. If you would look at the code quality of the most successful WordPress plugins you would be... uh, amazed? Compared to them WordPress' code quality is top notch. Yet, they probably bring in million/month from subscriptions. If you're curious see WpAllImport
Thankfully it's been a couple years since I had to touch a WordPress code base, but I remember being confused because I needed to define a route and couldn't figure out how to do so either in the code base or in documentation scattered about online. Eventually I realized that this was because WORDPRESS DOESN'T HAVE A ROUTER and you're supposed to just create .php files which are called and executed directly from the web server. True caveman smash-together-rocks shit.
This is not true. WordPress routes request in its own, admittedly shitty way, but it has a router. I don't remember where it is, but it exists. It parses rewrite rules and matches them against the request URI.
And ultimately, what is inside your pentest report ? Not a graph, a list of things to do:
- SMB signing.
- Don't use the domain admin to manage every machine.
- ...
The main reason this phrase is so popular, is that it panders to the hacker community: "We are the smart guys, all the defenders do is excel sheets."
IMHO, the nugget of truth in this is that defenders can spend considerable amounts of time on things that don't matter. Like doing CIS benchmark by hand on all servers. While missing the low-hanging fruits that would give them a strong security posture.
In a lot of companies, the defenders are just sysadmins that don't have any idea of what they should focus on.
I get your point but I think pentesters are perfectly capable of thinking in graphs, including web security. Bug chains are the immediate example, where a couple of CVSS 4-7 vulns can be turned into a full rce/whatever 9.8 equivalent. This bug chaining fundamentally occurs via elements of compromise i.e a graph traversal.
Bloodhound is great, and a nice visual tool for people to conceptualise attack graphs but it’s just a part of the process of understanding the target domain from an attackers perspective. No nice tool like bloodhound exists for web pentesting because a chain of compromise can’t simply be reduced into tool form there because a chain is often specific to the app and not an underlying framework, unlike AD where the security boundaries are well(ish) understood and codified.
Pentest reports include stuff like SMB signing and “don’t admin everything with your DA account ” because they are glowing hot nodes very early in a chain of compromise, meaning that is often how stuff gets popped IRL. It’s (hopefully) not that the pentester doesn’t understand graph thinking, it’s just the the first node in the graph represents effectively complete compromise, so why traverse?
SEEKING WORK: Pentest / AppSec / Training / Cybersecurity | Remote, France
Cybersecurity expert, with 8 years of experience, I have audited multiple complex systems. From Internet Gateway (Linux embedded), to innovative web apps and complex Active Directory environment of Healthcare providers.
All Linux binaries are compiled with PIE nowadays. You can run `checksec` on any binaries on Ubuntu, and it will have those properties.
(You can install checksec with `pip install pwntools`).
On the other hand, GLIBC has, to my knowledge, the most hardened heap implementation out there. And there are more mitigations for double-free and other heap exploits on GLIBC.
So in that regard, Alpine is less secure by using musl. Having a small, understandable system is a real advantage when it comes to security.
It was pretty clear to me that the comment was a description of the respective characteristics of glibc and musl in terms of security, while avoiding any conclusion: glibc has heap hardening, which is good for security, but a complex codebase, which is bad for security. Meanwhile, musl is small and understandable, which is good for security, but with a naive codebase that lacks hardening, which is bad for security. Which is better is intentionally left to the reader to avoid flamewars.
That's a charitable reading but it doesn't track with what they actually said. The first paragraph says that all modern Linux binaries are compiled with PIE, so Alpine has no advantage there. The second paragraph says that glibc is more secure than musl heap-wise. The third paragraph is the conclusion, which is that Alpine is less secure because it uses musl.
A sentence thrown on to the end of the conclusion should normally be read as reemphasizing the reasons for the conclusion unless it starts with a word like "though" or "however".
If you're smart enough to construct this analysis and critique, then you're smart enough to have reached the same conclusion the parent and I did.
I'm not charitable, it's just what made sense, like mentally fixing a typo instead of acting like you don't know, and can't figure out from context what someone meant just because they flubbed a letter or a word or something.
When a letter gets flubbed, it's nearly always possible to correct it from context alone. When a word is missing, it's sometimes possible to retrieve the original meaning but other times the missing word creates an ambiguity and you have to just pick a meaning. Faced with the ambiguity, your brain jumped in one direction, mine in another. You landed on the correct answer, I didn't, but there's no need to imply that my reconstruction was done in bad faith.
> I'm not charitable, it's just what made sense, like mentally fixing a typo instead of acting like you don't know, and can't figure out from context what someone meant just because they flubbed a letter or a word or something.
I mean, that's just what's called in Philosophy the principle of charity [0]. When evaluating a claim you should read it in its best light, which include glossing over minor inaccuracies and going straight to the main point.
So in that regard, Alpine is less secure by using musl. However, having a small and understandable system is a real advantage when it comes to security.
A line break in between the two sentences of the last paragraph may have made the commenter’s point clearer.
It seems to be they were only comparing the relatives benefits/drawbacks of glibc and musl, but with the way it is written the pro-musl comment feels out of place.
I run checksec on everything all the time and on all my Alpine nodes all the processes come back like this not pasting the full output for brevity... I have never see anything built by Alpine missing these flags.
COMMAND PID RELRO STACK CANARY NX/PaX PIE
init 1 Full RELRO Canary found NX enabled PIE enabled
[snip...]
crond 422838 Full RELRO Canary found NX enabled PIE enabled
> On the other hand, GLIBC has, to my knowledge, the most hardened heap implementation out there. And there are more mitigations for double-free and other heap exploits on GLIBC.
Re: Linux security, if someone can run any code at all on your system, you're screwed. Linux is swiss cheese. The only reason it isn't just as overrun with malware as Windows is nobody uses Linux for a desktop, so malware authors don't really try. (honestly I'd say modern Windows and MacOS both have a superior security architecture)
Linux distributions just have a different security model, based on trust. Maintainers form with developers a chain of trust from the repo to your machine.
Windows and MacOS on the other hand have an untrusted security model, everything is assumed to be potentially dangerous.
You're really not adding good content here. This is crap, that gets owned all the time... Why? What's the actual comparison? What model/approach makes the difference?
Please add something meaningful. Otherwise it's just ranting/fanboying over your preferences - we can be better than that on this board.
We really can't. Even if I reply with reasons, they will just be argued, ignored or downvoted by people who don't know what they're talking about. People only believe what they want to believe, or whatever a famous person says. (not to mention none of the people replying to me are providing any contrary evidence, just more spurious claims, but those with unpopular opinions get the downvotes)
Have you actually looked at the 0days? Almost always it's confined within the sandbox. You have to chain it with an sandbox breakout exploit to make it useful.
> ChromeOS, one of the more secure operating system s (behind QubesOS, on par with Android and iOS)
I don't know what features ChromeOS has over Linux but I wouldn't considered Android or iOS particularly secure, and Qubes isn't either directly, it's just a tool that can help in some cases.