f2fed1286d
Removed upstreamed patch: 010-padlock.patch
Changes between 1.1.1s and 1.1.1t [7 Feb 2023]
*) Fixed X.400 address type confusion in X.509 GeneralName.
There is a type confusion vulnerability relating to X.400 address processing
inside an X.509 GeneralName. X.400 addresses were parsed as an ASN1_STRING
but subsequently interpreted by GENERAL_NAME_cmp as an ASN1_TYPE. This
vulnerability may allow an attacker who can provide a certificate chain and
CRL (neither of which need have a valid signature) to pass arbitrary
pointers to a memcmp call, creating a possible read primitive, subject to
some constraints. Refer to the advisory for more information. Thanks to
David Benjamin for discovering this issue. (CVE-2023-0286)
This issue has been fixed by changing the public header file definition of
GENERAL_NAME so that x400Address reflects the implementation. It was not
possible for any existing application to successfully use the existing
definition; however, if any application references the x400Address field
(e.g. in dead code), note that the type of this field has changed. There is
no ABI change.
[Hugo Landau]
*) Fixed Use-after-free following BIO_new_NDEF.
The public API function BIO_new_NDEF is a helper function used for
streaming ASN.1 data via a BIO. It is primarily used internally to OpenSSL
to support the SMIME, CMS and PKCS7 streaming capabilities, but may also
be called directly by end user applications.
The function receives a BIO from the caller, prepends a new BIO_f_asn1
filter BIO onto the front of it to form a BIO chain, and then returns
the new head of the BIO chain to the caller. Under certain conditions,
for example if a CMS recipient public key is invalid, the new filter BIO
is freed and the function returns a NULL result indicating a failure.
However, in this case, the BIO chain is not properly cleaned up and the
BIO passed by the caller still retains internal pointers to the previously
freed filter BIO. If the caller then goes on to call BIO_pop() on the BIO
then a use-after-free will occur. This will most likely result in a crash.
(CVE-2023-0215)
[Viktor Dukhovni, Matt Caswell]
*) Fixed Double free after calling PEM_read_bio_ex.
The function PEM_read_bio_ex() reads a PEM file from a BIO and parses and
decodes the "name" (e.g. "CERTIFICATE"), any header data and the payload
data. If the function succeeds then the "name_out", "header" and "data"
arguments are populated with pointers to buffers containing the relevant
decoded data. The caller is responsible for freeing those buffers. It is
possible to construct a PEM file that results in 0 bytes of payload data.
In this case PEM_read_bio_ex() will return a failure code but will populate
the header argument with a pointer to a buffer that has already been freed.
If the caller also frees this buffer then a double free will occur. This
will most likely lead to a crash.
The functions PEM_read_bio() and PEM_read() are simple wrappers around
PEM_read_bio_ex() and therefore these functions are also directly affected.
These functions are also called indirectly by a number of other OpenSSL
functions including PEM_X509_INFO_read_bio_ex() and
SSL_CTX_use_serverinfo_file() which are also vulnerable. Some OpenSSL
internal uses of these functions are not vulnerable because the caller does
not free the header argument if PEM_read_bio_ex() returns a failure code.
(CVE-2022-4450)
[Kurt Roeckx, Matt Caswell]
*) Fixed Timing Oracle in RSA Decryption.
A timing based side channel exists in the OpenSSL RSA Decryption
implementation which could be sufficient to recover a plaintext across
a network in a Bleichenbacher style attack. To achieve a successful
decryption an attacker would have to be able to send a very large number
of trial messages for decryption. The vulnerability affects all RSA padding
modes: PKCS#1 v1.5, RSA-OEAP and RSASVE.
(CVE-2022-4304)
[Dmitry Belyavsky, Hubert Kario]
Signed-off-by: John Audia <therealgraysky@proton.me>
|
||
|---|---|---|
| .github | ||
| config | ||
| doc | ||
| include | ||
| LICENSES | ||
| package | ||
| scripts | ||
| target | ||
| toolchain | ||
| tools | ||
| .gitattributes | ||
| .gitignore | ||
| BSDmakefile | ||
| Config.in | ||
| COPYING | ||
| feeds.conf.default | ||
| Makefile | ||
| README_EN.md | ||
| README.md | ||
| rules.mk | ||
Welcome to Lean's git source of OpenWrt and packages
How to build your Openwrt firmware.
Note:
-
DO NOT USE root USER FOR COMPILING!!!
-
Users within China should prepare proxy before building.
-
Web admin panel default IP is 192.168.1.1 and default password is "password".
Let's start!
-
First, install Ubuntu 64bit (Ubuntu 20.04 LTS x86 is recommended).
-
Run
sudo apt-get updatein the terminal, and then runsudo apt-get -y install build-essential asciidoc binutils bzip2 gawk gettext git libncurses5-dev libz-dev patch python3 python2.7 unzip zlib1g-dev lib32gcc1 libc6-dev-i386 subversion flex uglifyjs git-core gcc-multilib p7zip p7zip-full msmtp libssl-dev texinfo libglib2.0-dev xmlto qemu-utils upx libelf-dev autoconf automake libtool autopoint device-tree-compiler g++-multilib antlr3 gperf wget curl swig rsync -
Run
git clone https://github.com/coolsnowwolf/ledeto clone the source code, and thencd ledeto enter the directory -
./scripts/feeds update -a ./scripts/feeds install -a make menuconfig -
Run
make -j8 download V=sto download libraries and dependencies (user in China should use global proxy when possible) -
Run
make -j1 V=s(integer following -j is the thread count, single-thread is recommended for the first build) to start building your firmware.
This source code is promised to be compiled successfully.
You can use this source code freely, but please link this GitHub repository when redistributing. Thank you for your cooperation!
Rebuild:
cd lede
git pull
./scripts/feeds update -a && ./scripts/feeds install -a
make defconfig
make -j8 download
make -j$(($(nproc) + 1)) V=s
If reconfiguration is need:
rm -rf ./tmp && rm -rf .config
make menuconfig
make -j$(($(nproc) + 1)) V=s
Build result will be produced to bin/targets directory.
Special tips:
-
This source code doesn't contain any backdoors or close source applications that can monitor/capture your HTTPS traffic, SSL is the final castle of cyber security. Safety is what a firmware should achieve.
-
If you have any technical problem, you may join the QQ discussion group: 297253733, link: click here
-
Want to learn OpenWrt development but don't know how? Can't motivate yourself for self-learning? Not enough fundamental knowledge? Learn OpenWrt development with Mr. Zuo through his Beginner OpenWrt Training Course. Click here to register.
Router Recommendation
Not Sponsored: If you are finding a low power consumption, small and performance promising x86/x64 router, I personally recommend the EZPROv1 Alumium Edition (N3710 4000M): Details
Donation
If this project does help you, please consider donating to support the development of this project.
Alipay
