W3m

I thought cli text based browsers were supposed to be secure? Did Holla Forums lie to me?

CVE-2016-9422 - github.com/tats/w3m/issues/8 stack smashed see analysis in github.com/tats/w3m/pull/19
CVE-2016-9423 - github.com/tats/w3m/issues/9 some buffer overflow
CVE-2016-9424 - github.com/tats/w3m/issues/12 heap write
CVE-2016-9425 - github.com/tats/w3m/issues/21 heap write
CVE-2016-9426 & CVE-2016-9427 - github.com/tats/w3m/issues/25 heap corruption itself should be only OOM. But it was affected by github.com/ivmai/bdwgc/issues/135 which become heap corruption

CVE-2016-9428 - github.com/tats/w3m/issues/26 heap write
CVE-2016-9429 - github.com/tats/w3m/issues/29 global-buffer-overflow write
CVE-2016-9430 - github.com/tats/w3m/issues/7 null deref
CVE-2016-9431 - github.com/tats/w3m/issues/10 stack overflow
CVE-2016-9432 - github.com/tats/w3m/issues/13 bcopy negative size
CVE-2016-9433 - github.com/tats/w3m/issues/14 array index out of bound read
CVE-2016-9434 - github.com/tats/w3m/issues/15 null deref
CVE-2016-9435
CVE-2016-9436
CVE-2016-9437 - github.com/tats/w3m/issues/17 write to rodata
CVE-2016-9438 - github.com/tats/w3m/issues/18 null deref
CVE-2016-9439 - github.com/tats/w3m/issues/20 stack overflow
CVE-2016-9440 - github.com/tats/w3m/issues/22 near-null deref
CVE-2016-9441 - github.com/tats/w3m/issues/24 near-null deref
CVE-2016-9443 - github.com/tats/w3m/issues/28 null deref

Other urls found in this thread:

github.com/tats/w3m/issues?q=is:issue is:closed
torproject.org
ics.uci.edu/~perl/pets16_selfrando.pdf
twitter.com/SFWRedditGifs

github.com/tats/w3m/issues?q=is:issue is:closed

Many more that have been recently fixed but not assigned CVE's yet.

They are secure, through obscurity. unfortunately, most CLI text browsers aren't written in a secure way or with security in mind like a graphical browser. Be wary of any C program that processes untrusted input.

You can remove the language predicate. No language is inherently safe from malicious input. Then you can remove the "untrusted input" selector as that describes practically all programs ever, and you're left with "Be wary of any program."

They're just more secure, by virtue of not support JS or audio/videos and a lot of other stuff. Nobody said they were perfect or even good.

Something like Chrome has an insane amount of attack surface, but it written with security in mind, is constantly fuzzed and tested and has exploit mitigations/sandboxing. Writing a reliable exploit for Chrome is very difficult.

Some dude casually fuzzing w3m found over 100 html parser issues in 2 months.

w3m is one browser. You have lynx and links/elinks, too.

C: 82.9%

who the fuck uses that shit, use links

Software written in C or C++ is never secure, необучаемые.

C suffers from it a lot more than many other languages, because of manual memory management without bounds checking. That's well-known and not controversial, except among ebin memesters.

What would "untrusted input" be in the case of GNUjump or M-x calc?

haha stupid idiots thought they safe with crap text browser

Tor Browser is 10 times safer yet it displays images


Tor Browser on High security settings blocks javascript/videos/audio, but is way safer, and shows images & css
And it provides free built in VPN

order now at torproject.org

Firefox/Tor Browser is still a security nightmare, any browser is, but specially firefox. If Tor Browser is your only line of defense, even with javascript disabled, then you're fucked.

Use Fifth Browser or Dooble if you want privacy/security.

That's why you ALWAYS have to assume that your browser has already been hacked. Which is why you should use Whonix no matter which browser you use, but Tor Browser has a smaller and more uniform fingerprint.

What about tor hardened. It's only available on linux but it takes a gigabyte of ram.

This is true. Text browsers present a smaller attack surface. That doesn't say anything about their code quality though, which can vary wildly. But a text browser programmed with security in mind will most likely end up safer than a graphical one that supports all the latest web subversions.
Plus you can run them direction on text console, which gets rid of other attack layers like X11, or monstrosities like WebGL.

You mean Tor Browser hardened (7.0.x)? That's alpha and stands out from the crowd. It's also much slower because the code is constantly checking for buffer overflows and shit like that.
Whatever you run keep it in some sort of container jail or virtual machine and you won't have to be as paranoid. But also replace the whole container once in a while.

That gave me a idea

Hope you're paid to be this retarded

Hope you're paid to be shilling for NSA

I had no clue w3m was on github, or even still worked on.

Hope you're paid to be shilling for NSA

If NSA can monitor all internet traffic, why would they pay people to encourage tor use? Your retarded.

Don't use Tor Browser-hardened. There has been a lot of discussion in the Tor mailing list to rename hardened to debug. The 'hardened' build is mostly used to debug with Address Sanitizer anyway.

The actual hardening feature, selfrando, will be moved to the regular Tor Brower alpha 7.0a2 soon.

So we will get hardened feature set eventually to stable? That could be a bad idea because most people don't have the hardware to run it smoothly and it will turn people away. Or is selfrando not the main thing that makes the hardened version slower and jittery?

Tor Project thinks a lot of about these issues. I haven't read this paper, but I think he performance impact of selfrando is negligible.

ics.uci.edu/~perl/pets16_selfrando.pdf

Tor Project is also working on a sandboxed version of Tor Browser. It will connect to Tor via unix sockets, so Firefox can run in a sandbox with no networking.

That will probably take a while though, that dev only just started with public commits and he was already experimenting with different methods for more than a year before that. It seems like it's very hard to do it right and major issues keep appearing.

Holla Forums's more full of retards than liars.

How many of the CVEs you listed would be mitigated by

CFLAGS="-DFORTIFY_SOURCE=2 -fstack-protector-all -fPIE"
LDFLAGS="-pie -z relro -z now"

and an appropriate AppArmor profile and firejail?

gcc also has ASAN now, but I don't know anything about it.